Re: ELF dynamic loader name [was: sbrk(2) broken]

On 1/4/08, Maxim Sobolev <sobomax_at_freebsd.org> wrote:
>
> Tim Kientzle wrote:
> >> "Sidegrading" is supposed to work now in HEAD; with a little hacking,
> >> you can build an amd64 world and kernel on the i386 world, install the
> >> kernel, reboot, and install world.  AFAIK, the required hacking
> involves
> >> copying /libexec/ld-elf.so.1 to /libexec/ld-elf32.so.1 ...
> >
> > I wonder when we'll have to standardize /libexec/<arch>/ to support
> > multiple architectures for things like ld-elf.so.1.  It used to only
> > be a concern for those rare people running diskless over multiple
> > architectures, but the case of i386 binaries on amd64 is a little
> > more common.
> >
> > On the other hand, if ld-elf.so.1 is fairly unique in this
> > concern, it might be simpler to rename it to:
> >    ld-elf-{i386,amd64,ppc,...}.so.1
>
> Good point, it's silly that i386 binary running on amd64 kernel requires
> ld-elf32.so.1, while ld-elf.so.1 when running on i386 kernel. It adds
> unneeded complexity for running i386 jail or chroot on amd64 for example.
>
> I wonder if we can do what Tim said - rename dynamic loader to actually
> include architecture name. I am pretty sure it would allow to remove
> quite few special cases from the kernel elf/emulation code and possibly
> from the cross build logic.
>
> -Maxim



While this doesn't count as an explicit vote against the rename, we can
solve the chroot problem easily.  I did this once already, but for some
reason never got around to committing it.

However, renaming ld-elf.so.1 is a bad idea in general.  Yes, it would have
been better to have had the arch name in there from the start, but it
doesn't.  It is unfortunate, but I feel that changing it will cause far more
pain across the board than it would solve for the specific case of chrooting
i386 binaries.  I don't think it is worth it.

There are a whole bunch of references to the ld-elf.so.1 name.  Not just in
our tree, but in external 3rd party code.  Even things like gdb "know" how
to handle ld-elf.so.1.  Getting those upstream folks to add additional
strcmp()'s for ld-elf-i386.so.1, ld-elf-amd64.so.1 etc will be hard enough,
and it will add another hurdle that minor platform maintainers have to
overcome.  ld-elf-mips-be-4Kc.so.1 anybody?  (ok, that last one is a
stretch)

Anyway, I'm not absolutely against it, but I think it will be a net loss
overall.  We'll have more pain than I think it is worth, especially since
the alternatives are much easier.

-Peter