qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers


From: Michael Weiser
Subject: Re: [Qemu-devel] [PATCH v2 5/5] linux-user: Add aarch64_be magic numbers to qemu-binfmt-conf.sh
Date: Wed, 20 Dec 2017 21:29:18 +0100
User-agent: Mutt/1.9.1 (2017-09-22)

Hi Laurent,

On Wed, Dec 20, 2017 at 05:43:34PM +0100, Laurent Vivier wrote:

> >> So it's not like on intel/AMD where we can execute a 32bit binary on a
> >> 64bit kernel?
> > 
> > An aarch64 CPU is capable of running arm (i.e. aarch32) code. And I
> > think this is supported as a multilib setup on Linux. But not in mixed
> > endianess as far as I know.
> > 
> > Looking at the code again, I'm confused now: Wouldn't the current logic
> > treat an actual i386 machine as capable of running x86_64 binaries
> > natively and omit registering the handler for x86_64?
> - on 32bit machine, we don't register the interpreter because the
> interpreter cannot work,

Okay, makes sense.

Meanwhile I verified that a little-endian arm kernel indeed refuses to
run a statically linked big-endian arm binary and vice-versa with
ENOEXEC ("Exec format error").

Looking at fs/binfmt_elf.c of the kernel, I understand that the kernel
makes no attempt to adjust for binary images of differing endianness.
Because the e_type ELF header field is byte-swapped in the big-endian
arm ELF binary, the kernel will see an invalid executable type and
return ENOEXEC.

Based on this I'm reasonably sure that a mixed little-/big-endian
userland is not currently possible on Linux. So I've gone with the
arm/armeb family split.

I'll push out a new version of the patch series with all the discussed
changes in a minute.
-- 
Bye,
Michael



reply via email to

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