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
