Kernel Run Time Linker Loader - KRTLD
Initial Overview
Below is an forum posting from Mike Walker to the PPC community and it is a good guide to follow, Rod Evans has added his comments to this also. We are currently deep into doing work to get to user land. A functional KRTLD has been up and running for several months now.
Now to Mikes discussion
I was involved in the bringup of amd64 so let me give some insight in how it was done previously.
The linker work (ld/krtld/ld.so.1) was kinda done in this order:
- first pass of the link-editor (ld) - add support for:
a) basic relocations (doreloc.c)
b) enable linking relocatable objects (ld -r)
c) enable static linking of a executable (kernel/unix)
- kernel & boot loader folks do bunches of work and get unix & krtld into memory
- work on krtld bootstraping code (it has to relocate itself) and then flush out krtld functionality
The nice thing about all our link-editors is that they share doreloc.c, which is of course the key to getting all relocations right. First make sure all the relocations displayed by "elfdump -r krtld" can be handled by doreloc(). Most of these have probably been handled so that you could build krtld in the first place.
If the krtld relocation requirements are anything like userland, they need to be very simple. User land only allows RELATIVE relocations in ld.so.1, but the kernel allows a larger family of relocations. But you shouldn't seen anything like GOT relocations etc.
As I recall, Mike sat with some kernel engineers and stepped through the bringup finding things like 32-bit relocation values being written where 64-bit values were expected (and visa-versa), or sign extension being carried out when it shouldn't have ... Then they had to go back to doreloc, fix the relocation code, and rebuild krtld. Rather time consuming I'm afraid.
- kernel folks now do bunches of more work to get to user land.
- Implement basic dynamic linking support in the link-editor (ld)
a ) building of shared libraries
b) building of PLT's
c) building of GOT's - port the run-time linker (ld.so.1). This involves both the bootstraping portion and the hand-off between kernel & userland. Work on loading & binding of objects, filling in PLT's - GOT's & what not
- Once all of the above is working - start back filling with the less critical functionality:
- Thread-Local Storage (both ld & ld.so.1)
Although support exists for this, there don't seem to be many users at present, so you might be able to leave this for a while. There is a handshake between ld.so.1 and libc for basic threads support, but I think this is all generic code (except for the low level mutex support in libc).
- link-auditing, especially PLT tracing which is platform specific
Yes, there are a number of platform specific support issues in ld.so.1, but again, they're for the rocket science folks, not so much main-stream functionality.
8) start beating on the linker test suite and flush out all of the missing functionality.