On Tue, Oct 10, 2023 at 11:44 PM Lorenz (xha) <m...@xha.li> wrote: > On Mon, Oct 09, 2023 at 01:29:52PM -0700, Philip Guenther wrote: > > On Mon, Oct 9, 2023 at 11:21 AM Lorenz (xha) <m...@xha.li> wrote: > > > > > hi misc@, > > > > > > i'm currently porting the hare programming language to openbsd and i am > > > having quite a few problems trying to use a linker script. i am always > > > getting a "/bin/ksh: .bin/hare: Invalid argument" error. > > > > > > so far i tried a lot of stuff like comparing a working version without > a > > > linker script, looking if any of the programm headers are missing, etc. > ... > > Read /usr/src/sys/kern/*exec* and review the logic around the 10 > > occurrences of EINVAL in that code. Presumably the differences you > > identified will point to one or more of them > > found it: PT_PHDRS is missing. i didn't identify that difference at > first tho. it's needeed for PIE if i understand correctly. >
Yeah. > why is ld not adding a PT_PHDR programm header? as far as i undestand, > PT_PHDR are the programm headers themselfs? PT_PHDR is the tag for an entry in the program headers that points to the program headers themselves. Some ELF files (for example, core files) have a program header but don't include a PT_PHDR entry in it. It's presumably not added by ld because you supplied a linker script and ld is trying to give you as much control as possible. Some of the other arguments you supplied may have required it to fill in other details, but including a DT_PHDR entry in the program header is apparently not one of them. As Theo says, this sort of thing makes linker scripts very subtle, with arch dependencies**, interactions with RELRO and W^X processing, and plain ABI weirdness. Even those of us who have written several of them often have to start from what 'readelf -lS' shows the default is to put together a starting point and massage it from there to achieve whatever our goal for going through this effort is. ** e.g., permissions on and immutability of .plt, .got, etc sections vary. Some archs have required some sections to be before or after others due to the CPU treating a limited range offset in some instructions as unsigned, so 'before' cannot be reached this is my linker script ... > i am moving the init functions in a > different section so that the hare runtime can execute them and not > libc. Well, the first issue with this is that libc doesn't invoke init functions, so there's some sort of misunderstanding going on. The .init section of the executable itself is invoked by the entry point code in crt0 before main is called, not libc. At a low level, that's done not via DT_INIT's value or the section name but via a symbol placed in the section which would presumably be carried along if you renamed the section, so you can't affect that. The .init_array section is handled by ld.so in dynamic programs where it's located via DT_INIT_ARRAY, and by crt0 in static programs where it's located via *_start and *_end symbols which I _guess_ would be from whatever ended up with the .init_array section name, so maybe renaming the section would prevent them from being invoked in that case, but I'm not sure and that an implementation detail that might change. (Moving a chunk of the crt0 code into libc would be possible (glibc did it, for example) and might make some evolution easier, but it hasn't happened.) ...but, backing up...what problem exists with the ordering that currently happens that makes you believe you need to interpose and have the "hare runtime" (sorry, I'm not familiar with that) execute them? How will you measure success of the change? Philip Guenther
