On 3/28/06, Joerg Schilling <schilling at fokus.fraunhofer.de> wrote:
> > How as this handled during the amd64 bringup, btw.?
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:
1) first pass of the link-editor (ld) - add support for:
- basic relocations (doreloc.c)
- enable linking relocatable objects (ld -r)
- enable static linking of a executable (kernel/unix)
2) kernel & boot loader folks do bunches of work and get unix
& krtld into memory
3) work on krtld bootstraping code (it has to relocate itself) and then
flush out krtld functionality
4) kernel folks now do bunches of more work to get to
user land.
5) Implement basic dynamic linking support in the link-editor (ld)
- building of shared libraries
- building of PLT's
- building of GOT's
6) 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
7) Once all of the above is working - start back filling with the less critical
functionality:
- Thread-Local Storage (both ld & ld.so.1)
- link-auditing, especially PLT tracing which is platform specific
8) start beating on the linker test suite and flush out all of the missing
functionality.
Anyway - that was kinda my working list when I've done this in
the past.
As a side note the xen for solaris folks have looked in revisiting
how krtld is involved in the initial bootstrap. Depending on that
progress you can remove krtld from the early dependencies.
_Mike_
>
> I believe that the Sun ld has been ported first.
>
> J?rg
>
> --
--
Michael Walker
mwalker at fins.com
