From owner-freebsd-current@FreeBSD.ORG Sat Jan 5 22:24:32 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 8790D16A418 for ; Sat, 5 Jan 2008 22:24:32 +0000 (UTC) (envelope-from peter@wemm.org) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.237]) by mx1.freebsd.org (Postfix) with ESMTP id D2CD613C45A for ; Sat, 5 Jan 2008 22:24:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: by hu-out-0506.google.com with SMTP id 28so1013979hub.8 for ; Sat, 05 Jan 2008 14:24:30 -0800 (PST) Received: by 10.82.108.9 with SMTP id g9mr32488075buc.34.1199571870107; Sat, 05 Jan 2008 14:24:30 -0800 (PST) Received: by 10.82.182.2 with HTTP; Sat, 5 Jan 2008 14:24:30 -0800 (PST) Message-ID: Date: Sat, 5 Jan 2008 14:24:30 -0800 From: "Peter Wemm" To: "Danny Braniss" In-Reply-To: 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> <477EFEAB.8090807@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=F8?=@freebsd.org, freebsd-current@freebsd.org, Jason Evans , Tim Kientzle , rgrav , Peter Schuller 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: Sat, 05 Jan 2008 22:24:32 -0000 On 1/4/08, Danny Braniss wrote: > > > Peter Wemm wrote: > > > > 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 > > > > > > While this doesn't count as an explicit vote against the rename, we > can > > > solve the chroot problem easily. > > > > Details? Does your approach also solve the problem of > > sharing /usr across different architectures (either in > > a diskless NFS environment or a dual-boot scenario with > > a shared /usr partition)? > > > > > However, renaming ld-elf.so.1 is a bad idea in general. ... 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 ... > > > > I'm not sure that I see the problem. What am I missing? > > 1) gdb is built to debug binaries for a particular architecture. > > (gdb/ARM can't debug gdb/i386 binaries) > > 2) gdb therefore only needs to check for "ld-elf-"`uname -m`".so.1", > > which is easy to handle when gdb itself is built. > > > > I can see some subtleties for cross-builds, but nothing > > outrageous. > > > > It also seems that your argument applies just as well to > > ld-elf.so.1 and ld-elf32.so.1. Either way, there's more > > than one ld-elf.so.1, and therefore more than one name > > to keep track of. > > > > I'm not championing the rename by any means, just trying > > to better understand the issues. The fact that amd64 can > > run i386 binaries but not vice-versa has a lot of subtle > > implications. Also, this is the first time that FreeBSD > > has really had large user bases on two fundamentally > > different architectures, so it's the first time we've > > really had to confront some of these support issues > > (such as the shared /usr scenario). > > > > Tim Kientzle > > The main issue is NOT sharing / or /usr or /usr/local, that is peenuts. > root and usr is less that 500 MGB, /usr/local though big, is handled > neatly by amd (the automounter). > cross building is one issue, but the real problem is sharing user's > binaries. > in Apple one can compile a binary for both i386 & ppc, and the binary is > twice as big. side note, I compiled such a program, but by mistake chose > two different binaries to be joined, and imagine my surprice when it acted > differently from expected. > We have come a long way since the days that a wrong architecture a.outwould > just coredump. > In the old days, we had ~/bin/$arch in our path to keep different > binaries, it was the days of VAX/Sun, but since i386 arrived, this has > been > forgotten. Now we are concidering to deploy amd64, and it would be nice > if it can be a 2way street - amd64 can run i386, but i386 should run the > i386 > version ... > > just blaberring before coffee. > danny It isn't very hard to do this at all. I did it as a proof-of-concept a few months ago: peter@overcee[2:18pm]/tmp/demo-218> cat foo.c #include main() { #ifdef __i386__ printf("Platform = i386\n"); #endif #ifdef __amd64__ printf("Platform = amd64\n"); #endif } peter@overcee[2:18pm]/tmp/demo-219> ./foo_i386 Platform = i386 peter@overcee[2:19pm]/tmp/demo-220> ./foo_amd64 Platform = amd64 peter@overcee[2:19pm]/tmp/demo-221> cat foo.c #include main() { #ifdef __i386__ printf("Platform = i386\n"); #endif #ifdef __amd64__ printf("Platform = amd64\n"); #endif } peter@overcee[2:19pm]/tmp/demo-222> which cc /usr/bin/cc peter@overcee[2:19pm]/tmp/demo-223> cc -o foo_amd64 foo.c peter@overcee[2:19pm]/tmp/demo-224> cc -m32 -o foo_i386 foo.c peter@overcee[2:19pm]/tmp/demo-225> file foo_* foo_amd64: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), for FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style, not stripped foo_i386: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), for FreeBSD 8.0 (800006), dynamically linked (uses shared libs), FreeBSD-style, not stripped peter@overcee[2:19pm]/tmp/demo-226> ./foo_i386 Platform = i386 peter@overcee[2:19pm]/tmp/demo-227> ./foo_amd64 Platform = amd64 peter@overcee[2:19pm]/tmp/demo-228> uname -m amd64 What I did was a half-dozen lines of a hack to our bmake glue for gcc. It is a hack though because I did it as specs overrides rather than have it figure the correct #include paths. This means my version doesn't interact with -nostdinc mode correctly. Doing it to correctly handle the paths isn't much harder. -Peter