I've been thinking a little about this lately, and a recent private
conversation prompted me to bring this back up.  There was a very, very old
thread I started on this topic, and I've long since forgotten the subject
line.

Anyway....  With all the headaches we'll have for the [first cut of] ELF
switchover in 1.5 for i386 and sparc, what is really stopping us from
creating a dynamic linker capable of using the new, ELF libc with an old,
a.out program binary?

There's a boatload of benefits here, beginning with the absence of "compat"
libraries in /emul or anywhere else, and the very important capability of
old (a.out) binaries being able to make use of bugfixes and enhancements in
a newer (ELF) libc.

Typically, ELF programs have a header that tell the kernel to load
/usr/libexec/ld.elf_so as the startup program.  a.out dynamic binaries,
instead, deliberately mmap and execute the a.out ld.so.

Relocations come in a few primary flavors for both formats:

- plain address (absolute relocated address of a symbol, possibly in pieces)
- PLT/GOT (absolute address is in a table, indexed by a PLT/GOT offset)
- PC-relative (location of insn with reloc is subtracted from symbol's addr)
- copy (address and size specifies a region of memory to copy into bss)

The last one is, I've heard, the most tricky to map from one format to
another, but we have a little leeway here--there are (or should be) very few
copy relocs in, at least, libc.  The sys_errlist change was a good example
of eliminating the need for a copy reloc (and avoiding the fixed-size copy
reloc problems).

If someone [I'm not volunteering until and unless I can get some *decent*
ELF platform-dependent dox] were to implement simple ELF parsing and
relocation, I'd hedge bets that a.out binaries could be allowed to use ELF
libraries.  On some platforms this may require dynamic generation of
trampolines for function calls--not a new concept--and on others, where the
calling convention is the same between formats, no conversion will be
required.

Before you say "it ain't possible", consider this:  Solaris does it.  (Run
the Solaris ldd on a SunOS 4.x binary sometime.)

[Quick] thoughts?

-- 
-- Todd Vierling (tv@pobox.com)