> 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 >
thank you for the explaination :) > 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? the problem is that in hare, the @init functions expect stuff like the global envpointer array (rt::envp) to be initilized. so that needs to be done before the @init functions are ran. so, digging deeper into crt0.c, i found the .preinit_array section which looks perfect to what i am trying to do. i added the init function to that section and indeed, it works as expected! :) now i don't need a linker script anymore; thanks for the help and showing me how horrible linker scripts are - lorenz
