multilib ABIs don't work

[tycho]

Please use the following bug reporting template to help produce actionable and reproducible issues:

A brief description

The two non-primary ABIs supported by Ubuntu are not functional under the Linux subsystem:

• i386/x86/ia32 The traditional 32-bit ABI. Built with gcc -m32.
• x32 An ABI that supports the full 64-bit instruction set and registers, but with a 32-bit address space. Built with gcc -mx32. More info about the ABI here and here.

Expected results

Applications built against the two ABIs should run.

Actual results (with terminal output if applicable)

+ cat test.c
#include <stdio.h>

int main(int argc, char **argv)
{
#if defined(__x86_64__) && defined(__ILP32__)
        printf("x32 ABI\n");
#elif defined(__x86_64__)
        printf("x86_64 ABI\n");
#elif defined(__i386__)
        printf("i386 ABI\n");
#else
#error "Unknown ABI"
#endif
        return 0;
}

+ for ABI in 32 64 x32
+ gcc -m32 -o test-32 test.c
+ ./test-32
bash: ./test-32: cannot execute binary file: Exec format error

+ gcc -m64 -o test-64 test.c
+ ./test-64
x86_64 ABI

+ gcc -mx32 -o test-x32 test.c
+ ./test-x32
bash: ./test-x32: cannot execute binary file: Exec format error

Your Windows build number

14393.10

Required packages and commands to install

The gcc-multilib package is sufficient to get started building i386 and x32 test applications.

[fpqc]

Pretty sure this is because they are not supporting the 32-bit ABIs at all. They're only aiming for 64-bit compatibility, not legacy stuff.

[tycho]

Fine, although x32 is not legacy. x86 is.

[aseering]

@tycho -- curious -- did you encounter this because you were just playing around, or do you have examples of programs that depend on it?

[tycho]

@aseering I develop programs against those ABIs and use it for servers. In the server context, I basically build any application that shouldn't reasonably consume more than 4GB of memory using the x32 ABI. This effectively caps its memory utilization. If an application leaks memory or is manipulated in some way to cause its memory usage to balloon too much, only the responsible process is killed by exhausting its own 4GB address space, instead of exhausting all of system memory and invoking the OOM killer which haphazardly kills arbitrary processes. There are other benefits of the ABI, but that's a pretty important one.

One nice thing for Microsoft on this issue is that a big chunk of the hard work (compiler, linking, packaging) are already done. They just need to implement the kernel side of it. Obviously not an easy piece of work, but easier than owning the userspace side in addition to that...

[aseering]

@tycho -- interesting; good to know about. I've had to deal with similar things, but have usually needed more control over the memory cap (more than 4gb or much less than 4gb) so have used ulimit. Admittedly it typically restricts virtual memory rather than physical; I haven't personally had to use the new cgroups-based stuff for restricting physical memory.

[fpqc]

I thought that most (desktop) Linux distros announced x86-32 support as legacy before 2015.

[aseering]

@fpqc -- you're correct. But x32 != x86_32.

I have seen x32 is kind of a specialty/niche tool in the past (though it sounds like there are more use cases for it): It has the benefits of most of the new 64-bit instruction set without the overhead of larger pointers.

[shinchiro]

I got this problem when cross-compile luajit with mingw for 32bit
https://github.com/LuaJIT/LuaJIT

[yuri-vashchenko]

I also see this issue. This is a show stopper for me.
I am using cross toolchain to build Linux for another architecture. The issue is that cross toolchain is built as 32-bit application and I cannot run it on WSL. I have installed all required multilib packages and libraries, but had no luck.
Whatever I try to do I get the same error:
cannot execute binary file: Exec format error
The file command returns:
file arm-none-eabi-gcc
arm-none-eabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld
-linux.so.2, for GNU/Linux 2.6.8, stripped

The issue is not only with this toolchain - I cannot run ANY 32-bit application which runs OK under Ubuntu on virtual machine

After trying to fix this issue for 2 days I finally gave up, installed Virtual Box and compile my project under Ubuntu on Virtual Machine.

Hope this will be fixed.

[aseering]

@yuri-vashchenko -- thanks for posting your experience. Just for your and others' information, the current expected behavior is that no 32-bit binaries will execute at all. That functionality is entirely absent in the current release, as far as I know.

That's obviously a major limitation for applications that need it. If it's something that you'd like, feel free to vote for it in the UserVoice forum:

https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-on-ubuntu-on-windo/suggestions/13377507-please-add-32-bit-elf-support-to-the-kernel

[yuri-vashchenko]

Thank you @aseering . voted

[tycho]

It is almost possible to get this working in a cheaty way via qemu-user on a Debian WSL install, but there are some problems with that (#2620).

Obviously slow-as-balls userspace emulation would be far less desirable than native execution, though.

[fpqc]

iirc, once qemu caches the JIT code, execution is full-speed because x64 emulation of x86 doesn't change the code that much.

[tycho]

"full speed" is kind of a misnomer, given that the JIT isn't very smart about the code it emits.

[mike-whittaker-work]

One final possibility, would be a compile or link (or multilib) option, that did the same job as -mx32 but also put in a 32<->64 bit translation layer (shim ?) for system calls, thus ensuring the binary as seen from the OS was wholly 64-bit. This would finally allow mx32-style programs to run under WSL.

[tycho]

This issue seems to be fixed by WSL2, since the Microsoft-vended WSL2 kernel supports the other ABIs:

#
# Binary Emulations
#
CONFIG_IA32_EMULATION=y
CONFIG_IA32_AOUT=y
CONFIG_X86_X32=y
CONFIG_COMPAT_32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_HAVE_GENERIC_GUP=y

And output from the test case shows it executes fine:

$ uname -r
4.19.104-microsoft-standard
$ gcc -mx32 -o test-x32 test.c
$ ./test-x32
x32 ABI