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

On 1/4/08, Danny Braniss <danny_at_cs.huji.ac.il> 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_at_overcee[2:18pm]/tmp/demo-218> cat foo.c
#include <stdio.h>

main()
{
#ifdef __i386__
        printf("Platform = i386\n");
#endif
#ifdef __amd64__
        printf("Platform = amd64\n");
#endif
}
peter_at_overcee[2:18pm]/tmp/demo-219> ./foo_i386
Platform = i386
peter_at_overcee[2:19pm]/tmp/demo-220> ./foo_amd64
Platform = amd64
peter_at_overcee[2:19pm]/tmp/demo-221> cat foo.c
#include <stdio.h>

main()
{
#ifdef __i386__
        printf("Platform = i386\n");
#endif
#ifdef __amd64__
        printf("Platform = amd64\n");
#endif
}
peter_at_overcee[2:19pm]/tmp/demo-222> which cc
/usr/bin/cc
peter_at_overcee[2:19pm]/tmp/demo-223> cc -o foo_amd64 foo.c
peter_at_overcee[2:19pm]/tmp/demo-224> cc -m32 -o foo_i386 foo.c
peter_at_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_at_overcee[2:19pm]/tmp/demo-226> ./foo_i386
Platform = i386
peter_at_overcee[2:19pm]/tmp/demo-227> ./foo_amd64
Platform = amd64
peter_at_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