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

[Samuel Thibault]

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

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

> 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
/proc/cpuinfo

Samuel