ELF dynamic loader name [was: sbrk(2) broken]
Danny Braniss
danny at cs.huji.ac.il
Sat Jan 5 00:03:41 PST 2008
> 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.out would
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
More information about the freebsd-current
mailing list