Re: ELF dynamic loader name

> Instead, the kernel automagically
> translates ld-elf.so.1 to ld-elf32.so.1 for 32-bit binaries, and gdb is
> none the wiser.

Ah!  I see.  So let me see if I understand:

   * Peter Wemm's concern about gdb is that the library
reference in the compiled binaries always be "ld-elf.so.1"
so that the debugger and other system tools can identify
references to this special library.
   * The kernel already has logic to translate refs to this
library to "ld-elf<platform>.so.1" for the single
special case of i386 on amd64 (even though "i386" seems to
be spelled "32" in this case).
   * "Side-grades" from i386 to amd64 have the complication of
having to rename ld-elf.so.1 at some point in the process.
Failure to do this at the correct point risks breaking the
entire system.

It still seems that renaming ld-elf.so.1 to ld-elf-<platform>.so.1
on disk would solve the side-grade problem (nothing to be renamed,
only a new ld-elf-amd64.so.1 to install), and the existing
kernel translation logic could be generalized to allow all
binaries to refer to ld-elf.so.1, thus addressing the gdb
problem in the same way it's been handled for this case for
some time.

I suppose the question boils down to:
  * If the kernel translates "ld-elf-so.1" to "ld-elf32.so.1"
for i386 binaries on amd64, why should it not do so for i386
binaries on i386 as well?  This special case seems to be the
root cause of at least some of the side-grade problems being
reported.

> (see src/sys/sys/imgact_elf.h, src/sys/kern/imgact_elf.c, and the
> various instances of Elf_Brandinfo, Elf32_Brandinfo and Elf64_Brandinfo
> in the kernel for the precise details of how this is done)

Thanks for the pointers; this isn't an area I've looked closely
at before...

Variant symlinks may also provide a solution to this, but I'm
not as familiar with the mechanism behind that, the current
implementation status, or how that would interact with
issues such as running i386 binaries on amd64 systems.

Of course, variant symlinks could also solve the more
general problem of handling other shared libraries correctly
in multi-architecture environments.  (Maybe even provide
a cleaner solution to the problem of Linux binaries on
FreeBSD?  Or is that too much to hope for? ;-)

Tim Kientzle