Re: x86_64 and x86 userland

[Bob Proulx]

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,

Actually, that is one of the possibilities.  And in that case I would
deny that it is a completely x86 userland.

1. User installs x86 kernel.  x86 userland.  Everything 32-bit.  I
   think this would be considered the "normal" installation.

2. User installs amd64 (aka x86-64) kernel.  /usr/bin/ is x86 but can
   now run amd64 binaries too.  So now the userland is a multiarch
   userland.

3. User installs amd64 (aka x86-64) kernel.  /usr/bin/ is 64-bit amd64
   binaries but the system can run 32-bit binaries too.  Userland is a
   multiarch userland.

> config.guess still gives you x86_64-unknown-linux-gnu as output.  (I
> have been told this, but not tried it myself).

That is correct.  The kernel returns x86_64 for 'uname -m'.  The gcc
toolpath is using x86_64 (with an underscore to avoid problems with
the dash) as the architecture string.  My understanding is that the
kernel uses whatever gcc uses and returns that for 'uname -m'.

> 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.

I don't know about 'setarch' but you can use the 'linux32' program.
It intercepts system calls and masquerades.  (Note this works the same
on ia64 too.  But I will keep this to amd64.)

  uname -m
  x86_64

  linux32 uname -m
  i686

  linux32 bash
  uname -m
  i686

As you can see with that last you can run a larger userspace and lie
to all of it about the current architecture.  A user could use that as
their normal environment and everything below that would believe it is
a i686 system.

> Would it not make more sense to have config.guess return i686 instead of
> x86_64?

I don't think that would be right.  After all you are running an amd64
architecture at that point.  The system can run 64-bit binaries.  That
is extremely important for some applications (such as mine :-).

> Is it just too late to make that change now?  How would it even
> be possible to detect a completely 32bit userland?

If the system has the possibility to run 64-bit binaries then it is
not a 32-bit userland.  Think nfs mounts.  Think cdroms.  And since
this can change dynamically a system can run 64-bit binaries in the
future.

If the system is really meant to be a 32-bit userland only then they
should run a 32-bit kernel just like classic 32-bit systems.  There is
no need to run a 64-bit kernel on an amd64/em64t processor.

I think at the point that the user has chosen to install the amd64
kernel (such as I have done) they have now moved into multiarch and
the system is no longer a pure x86 userland.  That was after all the
whole point of installing the 64-bit kernel.  Users can use a 32-bit
kernel if they don't want that.

I think someone may have thought that they required a 64-bit kernel on
am amd64/em64t processor but that is not true.  If they are only
running 32-bit applications and want things to be simple and in the
well travelled and well tested paths then I would recommend installing
a 32-bit kernel.  The 64-bit kernel works well but the standards such
as FHS address multiarch only poorly and so things are going to be
unsettled for the next few years while problems are hashed out.

The problem of multiarch is a little confusing.

Bob