Just having an odd error case, like out of memory, or file descriptors, means things that almost always works sometimes might not.
Via auxv slot AT_PHDR. Dwarf unwinding/exception handling also needs program headers for .eh_frame.
-
-
Right auxv was my guess. Yet to look into .eh_frame. It's just like with TLS, already mapped, libc just needs to find it?
-
Yeah. Normal model is that libgcc_eh/libunwind calls dl_iterate_phdr (in libc) which finds the program headers for main prog & each lib.
-
Then once it has the program headers it can search for PT_GNU_EH_FRAME or whatever it's called.
End of conversation
New conversation -
-
-
You can either let kernel loader complexity & interface surface to userspace grow O(n) in these sort of features, or let ELF handle it. :-)
-
I'm trying out the tradeoff where the kernel is more helpful within reason. I might change stuff once I do dynamic linking.
-
One way to do the tradeoff without attack surface is have the kernel map the code that does this stuff to userspace ala vdso...
-
Then the actual kernel need not do anything but open the ELF file; the code it mapped in userspace can handle the mmaps, etc.
-
I think this is an interesting approach and I have considered it. Maybe I'll do it down the road. It's like privsepping the kernel.
-
Of course with the whole program loader, the TLS parts is just a couple percent of fairly trivial code, not worth splitting out on its own.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.