Date: Tue, 7 Feb 2006 17:39:21 -0500 From: Coleman Kane <cokane@cokane.org> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit X libs? Message-ID: <20060207223921.GA18509@pint.candc.home> In-Reply-To: <20060207183608.GC699@turion.vk2pj.dyndns.org> References: <346a80220602032210o71367220v74033da94e3d83bb@mail.gmail.com> <XFMail.20060204144751.conrads@cox.net> <346a80220602051652u5b5f59fdx5fc715c22b84d133@mail.gmail.com> <20060206184111.GE699@turion.vk2pj.dyndns.org> <20060206194532.GA17347@pint.candc.home> <20060207183608.GC699@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 08, 2006 at 05:36:08AM +1100, Peter Jeremy wrote:
> On Mon, 2006-Feb-06 14:45:32 -0500, Coleman Kane wrote:
> >On Tue, Feb 07, 2006 at 05:41:11AM +1100, Peter Jeremy wrote:
> >> On Sun, 2006-Feb-05 19:52:30 -0500, Coleman Kane wrote:
> >> >Alright. I like the /usr/compat/ia32 idea as well.
> >>
> >
> >Problem is this: all your 32-bit apps require 32-bit library
> >counterparts for everything that they link against. For instance,
> >lets pretend that firefox wouldn't work on amd64.
>
> I'm aware of that. I expressed myself very poorly. What I meant to
> say was that that it would be nice if the kernel and rtld could
> automatically map between .../lib and .../lib32 depending on the ELF
> type, rather than requiring that all 32-bit code lived in
> .../compat/ia32. We also need the ability for a 32-bit app to exec a
> 64-bit app (whereas I believe the Linux compatibility layer required
> that an exec'd process always be inside the .../compat/linux tree).
Unless something's changed that I'm not aware of, then there is no
such restriction. IIRC, the linuxulator first searches the PATH
counterparts rooted at /compat/linux. If the path is not found there,
then the typical FreeBSD search path is used.
E.g.:
You want to exec 'vim'. Your PATH=/bin:/usr/bin.
Linuxulator effectively makes
PATH=/compat/linux/bin:/compat/linux/usr/bin:/bin:/usr/bin
(just tried this with /compat/linux/bin/bash and tried running chflags).
Also when open()ing files, the same rules are applied. If you are
creat()ing a file, then existence of the parent directory determines
creation location.
>
> A (Linux enthusiast) friend was mentioning that Linux has .../lib and
> .../lib64 in its amd64 variant. Solaris does much the same. I
> suspect that one reason for naming things this was round is that it
> vastly simplifies handling compatibility issues - basically, 32-bit
> apps just run (because they always point to the 32-bit RTLD and
> libraries), whilst 64-bit apps get compiled to point to the 64-bit
> versions. It's too late now, but this probably should have been done
> on FreeBSD as well. (The downside is that it makes the 'native'
> architecture look like 32-bits, with 64-bits as an addon).
I think that solaris did this due to the SPARC(32 bit) and UltraSPARC(64
bit) systems running the same distribution of Solaris. My guess is that
Linux does the same since its distribution model mimics that of Solaris
in many respects.
The canonical placement of lib64's and lib32's is configurable through
ldconfig and ldconfig32 however (and /compat/linux/sbin/ldconfig), an
in rc.conf. The point is pretty much moot, and subject to ones
preferences for organization.
> OTOH,
> a 32-bit app is always going to be smaller and, with less memory
> footprint, possibly faster - therefore is makes a degree of sense to
> only use 64-bits where it is needed (eg accessing lots of memory,
> doing lots of multi-precision integer arithmetic).
>
Its all relative... with the right code you aren't seeing an extreme
escalation in the size of the code.
> >Revisiting my earlier comment, we'd also need to maintain seperate
> >/var/db/pkg trees as well. You only want to have the necessary libs
> >build in 32bit to support your chosen set of 32bit ports. You'll need a
> >seperate pkgdb to keep track of them all.
>
> Good point. But it gets nastier when dealing with dependencies.
> LIB_DEPENDS will (always, I think) need to be the same ARCH.
> BUILD_DEPENDS and RUN_DEPENDS may or may not need to be the same ARCH.
> Things like {d,g,i}make, gm4 etc don't care whether they are being
> used to build 32-bit or 64-bit apps.
> Perl is messier - if perl is just being used to run configuration or
> installation scripts, its ARCH doesn't matter. If you're building a
> perl module it probably doesn't matter, unless the module itself
> contains some binary component that isn't ARCH-independent.
>
> >> - allow me to mount FreeBSD/i386 filesystems and execute programs in them.
> >
> >Correct me if I am wrong, but there is no such thing as a
> >"FreeBSD/i386 filesystem". The Berkeley FFS is the same across i386,
> >amd64, alpha, sparc64, ppc, and whatever else.
>
> Yes.
>
> > The only thing there is
> >is a "FreeBSD FFS with i386 programs on it", which would fall under the
> >same sort of rules that the linuxulator uses right now.
>
> This is what I was referring to. It I mount my FreeBSD/i386 filesystems
> on my FreeBSD/amd64 box, then they mostly fail to load the correct shared
> libraries (though I think I need to re-evaluate this - the ldconfig32
> hooks I thought I had are only in my -current FS and I was testing on
> -stable).
I guess my point is that the kernel can't logically tell what is a
'i386' FreeBSD installation from any other tree in the VFS.
Now, perhaps there'd be a syscall that had a list of paths that could
tell the system what paths (and below) to treat as a certain ELF type.
>
> >I think that it would be worthwhile to have the ability for a system
> >admin to connect ports up to buildworld
>
> I think this is work for much later.
>
> >I have an idea how infeasible this is, but it would be cool to be able
> >to specify library mappings from 32-bit land to 64-bit land. Say, for
> >instance, the amd64-bit versions of the libc string functions are faster
> >than the 32-bit libc ones.
>
> AFAIK, this won't work. amd64 and i386 code is not compatible. The
> amd64 CPU can be told that a particular process (task descriptor) is
> to be executed in "compatibility mode" but I don't believe it's possible
> to switch between them at runtime.
I don't mean 'compatibility mode', but perhaps have the 32-bit memset in
the 32-bit libc issue a syscall that makes it execute the 64-memset in
64-bit libc, with all of the pointer-remapping that is necessary. We
already do this for some code.
OTOH, this might not be worth our effort. It requires two extra kernel
switches that would otherwise not happen.
>
> --
> Peter Jeremy
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060207223921.GA18509>