Date: Fri, 4 Jan 2008 13:42:23 -0800 From: "Peter Wemm" <peter@wemm.org> To: "Maxim Sobolev" <sobomax@freebsd.org> Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Tim Kientzle <kientzle@freebsd.org>, Peter Schuller <peter.schuller@infidyne.com>, Jason Evans <jasone@freebsd.org>, freebsd-current@freebsd.org Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] Message-ID: <e7db6d980801041342k562a3459y39003036dc1a5528@mail.gmail.com> In-Reply-To: <477EA466.6060204@FreeBSD.org> References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <alpine.BSF.1.00.0801031305340.39341@goat.gigo.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/4/08, Maxim Sobolev <sobomax@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e7db6d980801041342k562a3459y39003036dc1a5528>