~lattis/muon#81: Tests failing on i386

Hi, it seems that muon's test suite tries to run x86-64 code on x86 architectures, and that obviously leads to test failures.

I'm not aware if this has been fixed in the latest master branch, as this issue has been reported by Debian's CI with the latest muon release (0.1.0). You can find the log here: https://salsa.debian.org/debian/muon-meson/-/jobs/3836747

For example:

[1/6] compiling assembly square_asm_cpp.p/square-x86_64.S.o
FAILED: square_asm_cpp.p/square-x86_64.S.o 
c++ -g -Og -Wpedantic -Wextra -Wall -I . -I '../../../../../tests/project/common/118 llvm ir and assembly' -MD -MQ square_asm_cpp.p/square-x86_64.S.o -MF square_asm_cpp.p/square-x86_64.S.o.d -o square_asm_cpp.p/square-x86_64.S.o -c '../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S'
../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S: Assembler messages:
../../../../../tests/project/common/118 llvm ir and assembly/square-x86_64.S:34: Error: `retq' is only supported in 64-bit mode

P.S. yes, muon has been now accepted in Debian and will be part of the upcoming Debian 12 release :) (I had to rename the binary to muon-meson, but I'll be able to undo that in the next release, since the "other muon" has been removed a few days ago)

Status: REPORTED
Submitter: ~tachi
Assigned to: No-one
Submitted: 1 year, 11 months ago
Updated: 8 months ago
Labels: No labels applied.

~eschwartz 1 year, 11 months ago

I have some vague memory that the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?

~tachi 1 year, 11 months ago

Il giorno dom 22 gen 2023 alle 18:18:10 +00:00:00, ~eschwartz outgoing@sr.ht ha scritto:

the platform detection code uses uname instead of the compiler defines, which triggers some interesting issues for multilib?

What do you mean with multilib? As far as I can tell, that CI runner uses only i386 packages (compiler, libs, etc). But maybe the underlying kernel of the container's host is amd64, so that's what could be causing the issue?

-- OpenPGP key: 66DE F152 8299 0C21 99EF A801 A8A1 28A8 AB1C EE49

~lattis 1 year, 11 months ago

~eschwartz is referring to https://todo.sr.ht/~lattis/muon/76, which could be the issue here, I'm not sure. 0.1.0 did pass all tests on all architectures alpine supports, so it seems likely that this is a case of muon reporting wrong system information.

~lattis 1 year, 11 months ago

It looks like host_machine.cpu_family() is indeed incorrectly returning x86_64 based on the log output. Do you happen to know what uname -m reports on that machine?

~tachi 1 year, 11 months ago*

uname -m reports x86_64, which could explain why tests are failing.

But I'm a bit puzzled, what does uname -m print? The actual underlying CPU architecture or the kernel's target architecture? Because tests pass without issues on the "official" Debian build machines, which seem to run on amd64 even for i386 builds, possibly with an i386 kernel; since GitLab CI's uses containers, the kernel is shared between the container and the host, so uname -m reports x86_64 for both. Does it make sense?

I'm unable to check if uname -m reports i386 (or x86) on the build machines, so I can't confirm this.

Output of uname -m, uname -a, env and cc -v on the CI container: https://salsa.debian.org/debian/muon-meson/-/jobs/3840046

Build log of the official buildd: https://buildd.debian.org/status/fetch.php?pkg=muon-meson&arch=i386&ver=0.1.0-2&stamp=1674429200&raw=0

Edit: according to https://db.debian.org/machines.cgi?host=x86-ubc-02, the build machine linked above uses an x86-64 CPU, so it is probably running an x86 kernel in a VM

~eschwartz 1 year, 11 months ago

Well, uname is a program for reporting the running kernel information. Containers are really no different from installing an i386 package on an x86_64 OS, and only running that i386 package -- files you're not using really don't matter, whether you choose to not use them or a sandbox forbids you from using them.

Oneric 8 months ago · edit

But I'm a bit puzzled, what does uname -m print? The actual underlying CPU architecture or the kernel's target architecture? Because tests pass without issues on the "official" Debian build machines, which seem to run on amd64 even for i386 builds, possibly with an i386 kernel

In case this is still relevant for you: It is possible to manually instruct the kernel to report itself as 32bit towards a process and its children via the personality syscall. util-linux provides the "setarch" and as a shortcut "linux32" utilities for this. Using them one can enter a 32bit chroot or container on a 64bit host with a matching 32bit uname value.