A Gentoo x32 release candidate
A Gentoo x32 release candidate
Posted Jun 7, 2012 2:51 UTC (Thu) by butlerm (subscriber, #13312)In reply to: A Gentoo x32 release candidate by nybble41
Parent article: A Gentoo x32 release candidate
You can recompile well written programs for an ABI like this without any source code changes. Manually adding offsets, on the other hand, is slower and makes for unusually ugly looking code.
> Also, is it too much to ask that x32 applications be capable of interacting with amd64 libraries?
It is conceivable that shims could be provided for some 64-bit libraries, but in the general case (C++ libraries for example) it is not even practical.
Most initial x32 systems are likely to be x32 only. I wouldn't expect a desktop distribution to come with full libraries for both x32 and x86-64, one would probably either have x32 releases that come with a handful of 64 bit packages, or x86-64 releases that come with a handful of x32 packages.
Posted Jun 7, 2012 3:57 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
I wasn't actually talking about providing shims. Rather, shared libraries would be compiled just as they are now in amd64 mode. The x32 programs would use 64-bit pointers in shared data structures and APIs, and 32-bit pointers in their own internal structures and APIs. Obviously, for this to work either the x32 parts or the dual-mode parts have to be marked somehow, e.g. with an attribute or a pragma line, so the compiler knows to use the larger pointers when compiling shared APIs for x32. Since any application with x32 components is guaranteed to run in a 32-bit address space, converting between the 64-bit and 32-bit pointers is trivial--the most significant 32 bits of the full-size pointers are always zero. Apart from marking the boundaries, the compiler can do all of the work.
> I wouldn't expect a desktop distribution to come with full libraries for both x32 and x86-64, one would probably either have x32 releases that come with a handful of 64 bit packages, or x86-64 releases that come with a handful of x32 packages.
The problem is the dependencies. To add just one moderately complex "foreign" package and you may end up needing duplicates of most of the system libraries. Some packages are relatively standalone, but what if you wanted, say, an x32 build of Chromium on an amd64 system? You'd need x32 builds of around 133 other packages[1] just to provide that one application.
[1] Estimated with: apt-cache depends --recurse -i chromium|awk '/^\s*Depends:\s+lib/{print $2;}'|sort -u
Posted Jun 7, 2012 4:15 UTC (Thu)
by mikemol (guest, #83507)
[Link]
You're *not* going to be able to interlink x32 and x86-64 binaries while sharing headers unless you make those headers aware of the differing binary representations of the types...and if you do that, you're making things significantly more complicated over a broad cross-section of code. That means tons of bugs.
As for having per-arch copies of the same binaries...that's already status quo on multilib systems. Not that big of a problem, really. x32 is poised to replace the old 32-bit ABI, with its segmented memory model and relatively limited register and CPU instruction set, with a 32-bit ABI with more registers and a higher-level guaranteed minimum for CPU instruction set availability. x32, in a sense, represents the new "i686" minimum compiler target for x86 systems with a 32-bit ABI.
Posted Jun 8, 2012 7:34 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Nope. Think about standard library. memcpy quite obviously does not need to convert pointers, but aio_read needs to do that. And if you pass structures with pointers to functions around then it becomes real ugly real fast. x86-64 NaCl is independent reimplementation of x32 architecture (we plan to rebase our change on top of x32 when it'll be stable) and for initial benchmarks we used standard x86-64 glibc linked with our x32-like binary. This was a disaster: it was possible to compile and run few simpler SPEC CPU2000 benchmarks this way, but things like 253.perlbmk just refused to work properly. When we've finally got the loader and libc ported we've dropped this mixed mode as a hot potato. It's not worth it, believe me. Right. This is a lot of work. But it's still simpler then to try to stitch Chromium from x32 pieces and x86-64 pieces.
A Gentoo x32 release candidate
A Gentoo x32 release candidate
A Gentoo x32 release candidate
Apart from marking the boundaries, the compiler can do all of the work.
Some packages are relatively standalone, but what if you wanted, say, an x32 build of Chromium on an amd64 system? You'd need x32 builds of around 133 other packages[1] just to provide that one application.