Re: x86_64 and x86 userland

[Noah Misch]

On Mon, May 02, 2005 at 10:31:57AM +0200, Ralf Wildenhues wrote:
> I have a question regarding systems with more than one ABI, specifically
> x86_64.  If you consider for example the Debian distribution which has a
> x86_64 kernel, but a completely x86 userland, config.guess still gives
> you x86_64-unknown-linux-gnu as output.  (I have been told this, but not
> tried it myself).
> 
> Now, if you configure a package and forget to add
>   --build=i686-pc-linux-gnu
> or maybe use the setarch tool to set personality (I do not even know how
> portable/available this is -- it exists in RedHat Fedora), it may break,
> e.g. because of the __x86_64__ preprocessor define.

The compiler generates x86 binaries but defines __x86_64__?  Weird.

> Would it not make more sense to have config.guess return i686 instead of
> x86_64?  Is it just too late to make that change now?  

Maybe.  If the sole purpose of host triplets was to characterize the binary $CC
produces, then that would be highly appropriate.  They serve other purposes as
well, though.  With this change, a binutils built natively on this system will
be i686; as config.guess stands, it will be x86_64.  Is that change okay?

IMO, a tool that makes `uname' returns `i686' is more appropriate.  It sounds
like `setarch' may do that.  SLES 9 for ppc64 includes a `powerpc32' tool that
runs a program with ppc32 personality; `powerpc32 uname -m' prints `ppc'.  If
Debian wants to keep userspace in the dark about the true nature of its kernel,
it could run the entire userspace with 32-bit personality.

> How would it even be possible to detect a completely 32bit userland?

You could test the compiler with `sizeof(char *)'.  To ensure that a 64-bit C
library is also available, link a program that uses a library function.