From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 22:08:36 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA0B16A418 for ; Fri, 4 Jan 2008 22:08:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6C94C13C455 for ; Fri, 4 Jan 2008 22:08:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: by fk-out-0910.google.com with SMTP id b27so9934533fka.11 for ; Fri, 04 Jan 2008 14:08:36 -0800 (PST) Received: by 10.82.146.14 with SMTP id t14mr30571656bud.9.1199482943133; Fri, 04 Jan 2008 13:42:23 -0800 (PST) Received: by 10.82.182.2 with HTTP; Fri, 4 Jan 2008 13:42:23 -0800 (PST) Message-ID: Date: Fri, 4 Jan 2008 13:42:23 -0800 From: "Peter Wemm" To: "Maxim Sobolev" In-Reply-To: <477EA466.6060204@FreeBSD.org> MIME-Version: 1.0 References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> <200801032200.25650.peter.schuller@infidyne.com> <8663yac62d.fsf@ds4.des.no> <477E72FC.5070304@freebsd.org> <477EA466.6060204@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Tim Kientzle , Peter Schuller , Jason Evans , freebsd-current@freebsd.org Subject: Re: ELF dynamic loader name [was: sbrk(2) broken] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 22:08:37 -0000 On 1/4/08, Maxim Sobolev 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// 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