s0ph0s|alt has quit [Quit: My ZNC server died. Probably updating my kernel...]
hendursaga has joined #riscv
davidlt has joined #riscv
BOKALDO has joined #riscv
rlittl01 has joined #riscv
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #riscv
arlen has quit [Ping timeout: 264 seconds]
davidlt has quit [Ping timeout: 252 seconds]
<dh`>
jemarch: duly noted
<dh`>
but, you know, one does get tired and frustrated dealing with such problems over the years
<dh`>
:-|
<dh`>
on the subject of paired relocations: gods no please
<xentrac>
sure, but I'm tired of dealing with them from non-GNU sources mostly
BOKALDO has quit [Quit: Leaving]
<jrtc27>
dh`: I agree that paired relocation really suck but unless you have a better suggestion I don't see how it can be avoided for RV£2
<jrtc27>
*32
<dh`>
xentrac: it is possible that I hold established projects to a somewhat higher standard
<sorear>
RV£ snrk
<dh`>
but I'm thinking of stuff like discovering that an autoconf test is not working because it's not including standard headers, and then discovering that it can't because it relies on UB that the compiler rejects as soon as standard headers are present
<dh`>
or the library code that gets cutpasted over and over again into all kinds of packages and needs to be patched over and over again because it doesn't work/isn't portable and never gets fixed upstream
<dh`>
:-|
<dh`>
anyway
<sorear>
that's one way to deal with the "25 letters for standard extensions" problem
<dh`>
that in turn reminds me of the old joke about GNU wanting everything to be 8-bit clean so they can use accented characters as command-line options :-)
<sorear>
was that before utf8 was a de facto standard
<dh`>
long before
<dh`>
like 1990
<dh`>
anyway I'm not on top of the exact situation with riscv and paired relocations so I don't have any suggestions (besides "never use rel, only rela")
<sorear>
the musl dynloader mostly doesn't even support arch-specific relocation types
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
<dh`>
I remain of the opinion that if we ever manage to move past ELF we should be going back to jumptables for routine runtime linking
<xentrac>
dh`: all C software relies on UB
<dh`>
but that's neither here nor there
<dh`>
xentrac: to varying extents
<dh`>
there's a bunch of standardish autoconf tests that rely on being able to do things like "char strchr();"
<xentrac>
but yeah everything related to autoconf and automake is horrible
<dh`>
well yes
<xentrac>
but what choice did we have in 01997?
<dh`>
a lot
<xentrac>
a lot of things that were even worse, as I recall
<dh`>
you can always write configure scripts by hand, and I did for a long time
<jrtc27>
please no
<xentrac>
heh
* jrtc27
glares at nginx with extreme prejudice
<jrtc27>
autoconf sucks but it's standard suckiness
<dh`>
granted many people don't seem to be able to do it
<xentrac>
or you can avoid writing nonportable software
<dh`>
oh another thing is packages that fail parallel builds because they use automake
<xentrac>
which is an amusing thing for me to say since I'm literally as we speak writing an interpreter in i386 assembly with hardcoded Linux system calls
<dh`>
fie!
<jrtc27>
dh`: by jumptables do you just mean what calling dllimport functions does on windows?
<jrtc27>
ie what the MIPS ABI is, but only for imported functions
<dh`>
I don't know what windows does, haven't coded on windows since ages
<jrtc27>
-fno-plt
<jrtc27>
is basically how it works for dllimport functions
<jrtc27>
everything else is known to be within a library, because symbols are the equivalent of having protected visibility and you can't call exported functions without knowing they're being imported
<jrtc27>
ie completely removes the cross-TU issue that motivates using PLTs in ELF
<dh`>
but basically what I mean is: at static link time resolving external references to a library/interface and function number and using the function number to call through a table that lives in the imported object
<xentrac>
cross-TU?
<jrtc27>
cross-translation-unit
<xentrac>
oh, of course, thanks
<jrtc27>
dh`: that doesn't work
<jrtc27>
if the table lives in the imported object the function number isn't stable across library versions
<dh`>
sure it does. it requires the library ABI to be stable
<dh`>
or rather, it requires libraries to have ABI specifications
<dh`>
this is no bad thing
<jrtc27>
it requires the table order to be deterministic and no exported functions to be even *added*
<dh`>
you can add at the end
<jrtc27>
and how does that get done automatically?
<jrtc27>
it requires human intervention to tell it what new functions there are
<jrtc27>
which for the most part is a no go
<dh`>
yes, like I said, it requires libraries to have ABI specifications
<xentrac>
I guess you write a file that defines the library ABI?
<sorear>
interface method tables!
<jrtc27>
sure, but how many people are writing symbol version files for their libraries
<jrtc27>
vs how many people just do gcc -o libfoo.so -shared and be done with it
<xentrac>
yeah, that's what I do
<jrtc27>
adding more steps just makes people hate you
<dh`>
people who can't be arsed to do it properly can bump the major every release
<jrtc27>
great so now distros hate your spec
<dh`>
distros hate dll hell more
<jrtc27>
and you've just reinvented the pain of languages without a stable ABI
<xentrac>
just recompile everything from source every time, it's the only way to be sure
<jrtc27>
dll hell *comes* from having multiple versions
<jrtc27>
if versions are compatible there *is no dll hell*
<dh`>
multiple versions are a given
<jrtc27>
no, not if they remain ABI compatible
<dh`>
eventually someone needs to make a breaking change
<jrtc27>
yes, but "once every few years" vs "every month" is completely different
<dh`>
especially people who can't be arsed to take basic precautions about making their ABI stable
<jrtc27>
the latter leads to chaos and nothing ever works because you're constantly in the middle of 100 different transitions
<xentrac>
once every few years is basically the same as every month
<jrtc27>
no it's completely different
<xentrac>
both are far too often for me
<xentrac>
for my software to stop working
<jrtc27>
I mean it varies hugely between libraries
<jrtc27>
many go a decade or longer without bumping soname
<jrtc27>
some bump every few months because they CBA to do stable ABI
<jrtc27>
*a
<dh`>
right now if you have a chain of libraries and one of them updates you have to recompile everything else or face completely unpredictable behavior
<xentrac>
well
<jrtc27>
that's not true
<xentrac>
you might be able to check that the header files didn't change
<jrtc27>
anyway, it's 6am for me, I should sleep
<dh`>
and people continue to operate under the assumption that you don't have to bump the major if you add new symbols, which is not true
<jrtc27>
but with my debian developer hat on, no, you're very wrong on a lot of this
<xentrac>
sleep well. thanks for the intriguing chat
<xentrac>
dh`: why is it not?
<dh`>
we should continue this then because i have my netbsd pkgsrc hat on :-)
<xentrac>
this sounds promising but maybe you should negotiate a time when you're both awake
<dh`>
xentrac: suppose you have libfoo.so -> libbar.so -> libbaz.so -> program
<dh`>
erm, libfoo.so <- libbar.so <- libbaz.so <- program
<dh`>
where <- means "linked to"
<xentrac>
right
<dh`>
foo contains foo(), bar contains bar(), baz contains baz()
<dh`>
update libfoo.so, the maintainer thought it was a good idea to add a baz()
<dh`>
run the program
<dh`>
there can only be one baz(), which you get at runtime depends on the ordering of internal glop in the elf files
<dh`>
no dynamic linker I'm aware of detects the conflict, either.
<jrtc27>
recompiling doesn't fix that, that's a completely separate issue
<dh`>
recompiling will fail
<jrtc27>
and no they don't because symbol interposition is (currently) a featureTM
<dh`>
so you at least become aware of the problem
<xentrac>
yeah, I used symbol interposition for Y2K testing on SunOS 4 in 01997
<dh`>
symbol interposition has its uses but needs to be much more restricted
<xentrac>
easiest way to find out what programs would do in 02000
<jrtc27>
only if foo and baz's declarations of baz() (a) conflict in prototypes (b) are declared at the same time in a translation unit
winterflaw has joined #riscv
<jrtc27>
with how complex libraries are, and the amount of indirection you're proposing, in practice those easily go unnoticed even after a recompile
<dh`>
no, you'll get a multiply defined symbol error at link time unless one of them helpfully made their symbol weak
<dh`>
(weak symbols are a whole different rant)
<xentrac>
am I evil for putting a weak main() in my shared libraries? :)
<dh`>
yes :-p
<dh`>
anyway there are many other ways to get hosed
<jrtc27>
that's not true for dynamic linking, you won't get an error
<jrtc27>
even for static linking you'd only get it if both objects in the archives are pulled in
<dh`>
you should get one at static link time
<jrtc27>
depends what else is in the translation units they're in
<xentrac>
I guess I could just set an entry point address on the shared library, couldn't I? there's no need to use a weak main
<dh`>
because .so files are single objects
<jrtc27>
if both have a baz.o that contains baz and nothing else, you don't notice there either
<dh`>
xentrac: doubt that works
<xentrac>
dh`: how come?
<jrtc27>
(for static linking)
<dh`>
because you can't run a library image
<jrtc27>
for dynamic linking you don't notice because they're not in the same object
<jrtc27>
and that is not an error
<dh`>
or maybe nowadays you can because it looks like a PIE?
<jrtc27>
as I said, interposition is a feature
<jrtc27>
(go try it yourself)
<dh`>
last I checked because each is a single object it'll import both objects and fail
<dh`>
but maybe not
<dh`>
it's even worse if it doesn't fail
<dh`>
anyway go to sleep :-)
<xentrac>
well, on this random .so I tried running, I got a segfault
<dh`>
anyway there are many other ways to be hosed
<dh`>
and I need to make dinner, it's past 1am
<xentrac>
but I suspect maybe the entry point address in its ELF header is just totally spurious
<jrtc27>
you only get the error if (a) both symbols exist in the same object (so static linking, or you have conflicting .o's you explicitly link) *and* (b) both objects are pulled in due to dependencies (one definition shadows another so you need some other needed symbol to force the inclusion of the second object)
<xentrac>
right, if baz.o in libfoo.a only defines baz(), the static linker just won't pull in baz.o from libfoo.a
<jrtc27>
(which has to be true, otherwise specifying the same .a multiple times to deal with circular references would break)
<xentrac>
unless there's nothing conflicting with it
<xentrac>
I did a PLT-like thing earlier tonight with the wickedest of motives
<xentrac>
on i386 `call foo` is 5 bytes but `call *44(%ebp)` is only 3 bytes
<xentrac>
so I shrank my interpreter by 16 bytes. however, the disassembly is noticeably less readable now
<sorear>
that's just because your disassembler isn't in on the game
<xentrac>
kinda, yeah
<xentrac>
I mean it would kind of have to do whole-program dataflow analysis to be sure I wasn't setting %ebp to something else somewhere
<xentrac>
once I have it working well on i386 I'll see how RV32GC compares on code density
<sorear>
no the disassembler can just emit pseudo-call macros
<xentrac>
hmm?
<xentrac>
what do you mean?
<sorear>
call_via_ebp foo, or call *FOO(%ebp), etc
<sorear>
if you don't _lie_ about what the actual instruction is you don't need any dataflow
<xentrac>
well, so, in my objdump output, I have
<xentrac>
804825a:ff 55 04 call *0x4(%ebp)
<xentrac>
ugh, sorry about I
<sorear>
(you shouldn't do the lies regardless because sometimes instruction length and byte values matters. although modern x86 syntax doesn't allow you to express all noncanonical encodings :( )
<xentrac>
the corresponding source code says
<xentrac>
do skip_whitespace
<xentrac>
which invokes a gas macro that expands to
<xentrac>
call *(\name\()_address-globals)(%ebp)
<xentrac>
in this case
<xentrac>
now, globals and skip_whitespace_address both appear in nm output on the executable
<xentrac>
but I'm not sure gas emits relocations for them pointing at that byte of the assembly
<xentrac>
my guess is that it doesn't because if skip_whitespace_address were to somehow get moved hundreds of bytes away from globals, that instruction encoding would need to use a different offset format, and I don't think that's the kind of thing ld normally does
<xentrac>
but I'm open to hearing about the many things in heaven and earth that are not dreamed of in my philosophy
<xentrac>
I'm not even sure how to list all the relocations in a .o file
<xentrac>
oh, readelf -a. which doesn't show any relocations for any of those symbols
<xentrac>
so how is the disassembler supposed to know that "4" came from "skip_whitespace_address - globals"?
pabs3 has quit [Quit: Don't rest until all the world is paved in moss and greenery.]
<xentrac>
if it knew that the actual value of %ebp was globals, it could see that by adding 4 to it one arrives at skip_whitespace_address
pabs3 has joined #riscv
davidlt has joined #riscv
<dh`>
huh, it doesn't generate a multiply defined symbol error
<dh`>
did that change at some point? seems entirely wrong
kito-cheng has quit [Quit: Connection closed for inactivity]
davidlt has quit [Ping timeout: 252 seconds]
elastic_dog has quit [Ping timeout: 252 seconds]
elastic_dog has joined #riscv
loki_val has joined #riscv
crabbedhaloablut has quit [Ping timeout: 276 seconds]
geranim0 has joined #riscv
llamp[m] has joined #riscv
geranim0 has quit [Ping timeout: 265 seconds]
arlen has joined #riscv
Sos has joined #riscv
davidlt has joined #riscv
kido has joined #riscv
Gravis has joined #riscv
jacklsw has joined #riscv
Sos has quit [Quit: Leaving]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
danielinux has quit [Ping timeout: 252 seconds]
danielinux has joined #riscv
bgamari_ has joined #riscv
bgamari has quit [Ping timeout: 252 seconds]
cengiz_io has quit [Ping timeout: 240 seconds]
arnd has quit [Ping timeout: 268 seconds]
theruran has quit [Ping timeout: 268 seconds]
NishanthMenon_ has quit [Ping timeout: 268 seconds]
kido has quit [Ping timeout: 268 seconds]
adomas has quit [Ping timeout: 268 seconds]
arnd has joined #riscv
cengiz_io has joined #riscv
mobius has quit [Ping timeout: 268 seconds]
seds has quit [Ping timeout: 250 seconds]
JSharp has quit [Ping timeout: 260 seconds]
theruran has joined #riscv
NishanthMenon_ has joined #riscv
adomas has joined #riscv
JSharp has joined #riscv
seds has joined #riscv
mobius has joined #riscv
kido has joined #riscv
rlittl01 has quit [Read error: Connection reset by peer]
rlittl01_ has joined #riscv
vagrantc has joined #riscv
aburgess has quit [Ping timeout: 252 seconds]
[itchyjunk] has quit [Quit: Leaving]
<xypron>
Is there a standard defining that boot hart ID and device tree are passed in registers a0 and a1 to the next boot stage as we do when invoking U-Boot or Linux from OpenSBI?
<jrtc27>
I don't think it actually is specified anywhere
<jrtc27>
both for OpenSBI being called and for OpenSBI calling things
<palmer1>
it should be written down, we at least used to have it in the platform spec
<jrtc27>
I don't think it ever actually was in the platform spec
<jrtc27>
just on the mailing list that it should be there
<jrtc27>
it was in sifive fusdk specs though somewhere
<jrtc27>
IIRC
<palmer1>
well, I can't find it ;)
<palmer1>
I remember having written it down somewhere, but maybe I'm just wrong
<jrtc27>
I definitely remember seeing it in at least one place, and I thought it was *somewhere* other than sifive docs, but can't for the life of me find or remember where that was
<jrtc27>
of course "what should a1 be when using ACPI" is an interesting question ;)
<palmer1>
IMO we had something vague like "a1 is the platfor description format" or whatever, so we could do ACPI as well
<palmer1>
DT itself has a magic, IDK if ACPI does
<jrtc27>
"RSD PTR "
frost has quit [Quit: Connection closed]
aburgess has joined #riscv
cousteau_ has joined #riscv
cousteau_ has left #riscv [#riscv]
geranim0 has joined #riscv
geranim0 has quit [Remote host closed the connection]
geranim0 has joined #riscv
geranim0 has quit [Ping timeout: 252 seconds]
<AhmedCharles[m]>
I thought it was mentioned vaguely in the SBI spec.
jacklsw has quit [Quit: Back to the real life]
<jrtc27>
only for the HSM extension
<jrtc27>
there's nothing about the boot hart
<palmer1>
ya, I thought we'd copied the HSM stuff from the legacy boot mechanism
<palmer1>
but I couldn't find it anywhere, so I'm not 100% sure on that
aburgess has quit [Ping timeout: 265 seconds]
<gordonDrogon>
this might sound like a complete noob question (but hey, I'm a noob to RISC-V, so ;-) But is there a standard for the reset vector? (And am I right in thinking I need to noodle a CSR to set the interrupt vector(table) ?
<pjw>
The tech-config task group has high aspirations for this sort of thing, but we'll see whether vendors actually will care about this type of platform interface
zjason` has quit [Read error: Connection reset by peer]
zjason` has joined #riscv
BOKALDO has quit [Quit: Leaving]
<jrtc27>
that only tells you about the architecture, not peripherals
<jrtc27>
and I fully expect a lot of vendors to just ignore it because it's extremely complicated
<jrtc27>
(and having board-specific firmware is hardly a big deal, it tends to be anyway)
valentin has quit [Quit: Leaving]
arlen_ has joined #riscv
arlen has quit [Ping timeout: 252 seconds]
jellydonut has quit [Quit: jellydonut]
jellydonut has joined #riscv
cp- has quit [Read error: Connection reset by peer]
[itchyjunk] has joined #riscv
vagrantc has quit [Ping timeout: 250 seconds]
s0ph0s has joined #riscv
pecastro has quit [Ping timeout: 252 seconds]
<sorear>
gordonDrogon: reset vector is implementation defined, interrupts go to mtvec or stvec (see the descriptions of those CSRs in the privileged ISA manual)