[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] exec: Allow loading x86_64 executables on x86_64

From: Samuel Thibault
Subject: Re: [PATCH] exec: Allow loading x86_64 executables on x86_64
Date: Fri, 12 May 2023 01:00:47 +0200
User-agent: NeoMutt/20170609 (1.8.3)

Sergey Bugaev, le jeu. 11 mai 2023 18:25:43 +0300, a ecrit:
> On Thu, May 11, 2023 at 6:02 PM Samuel Thibault <samuel.thibault@gnu.org> 
> wrote:
> > See the commit I had just pushed ;)
> Hm, but that doesn't make sense to me. If we want a particular tool --
> Unix uname(1) -- to output "i386" when running i386-gnu software on
> x86_64 hardware (and I don't actually know whether we want that, but
> at least Linux seems to still return machine = "i686" ),

We do need that. Various configure scripts and whatnot expect "uname -m"
to be returning what the distribution is supposed to be using as main

> we should do that at some upper layer like maybe in uname(2)
> implementation in glibc / proc server.
> Why is the exec server even written this way? Surely it already knows
> what arch it's built for -- this can be determined at compile time.

Not necessarily. On Linux it's *not* the bitness of the program that
defines what uname() reports. It's the personality() system call, that
changes what the process sees. So that a 32bit program can either see
i686 or x86_64 depending on what the caller prepared. In our case we
decided to have a 32bit-xor-64bit gnumach, so it's even simpler.

> But should not be a reason for the kernel to lie to userspace about
> what CPU it is running on, no?

Our USER32 kernel only expose 32bit support, so it doesn't seem lying to

> On the other hand this really raises binary compatibility concerns: if
> new, i386-compatible CPU types are added and the kernel starts
> returning them, userspace wouldn't recognize them until it is updated
> (both in code, and rebuilt) to understand the new types.

Yes, and that has been happening for i[3456]86 on Linux, and it posed
enough troubles that they stopped doing it at all, and let programs that
actually care about the detail of the actual cpu read that from


reply via email to

[Prev in Thread] Current Thread [Next in Thread]