- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Packages → Packages: Stable
- Assigned To No-one
- Operating System i486
- Severity Low
- Priority Low
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Archlinux32
Opened by Andreas Baumann - 15.11.2018
Last edited by Andreas Baumann - 31.01.2019
Opened by Andreas Baumann - 15.11.2018
Last edited by Andreas Baumann - 31.01.2019
FS#57 - libc fails on AMD-K6
pacstrap /test base
LD_LIBRARY_PATH=/test/usr/lib gdb –args /test/bin/bash results in:
Program terminated with signal SIGILL, Illegal instruction. #0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6 (gdb) bt #0 0xb7619991 in strcmp () from /test/usr/lib/libc.so.6 #1 0xb75bd41f in setlocale () from /test/usr/lib/libc.so.6 #2 0x0076b7f2 in ?? () #3 0x0053acf6 in ?? () #4 0xb75b3a31 in __libc_start_main () from /test/usr/lib/libc.so.6 #5 0x0053e561 in ?? ()
So, getting the exact failing opcode is hard.
2.28-5.0 was ok,
2.28-5.2 is not.
So it’s something we changed or something changed on one of the i486 build slaves.
Happens only on the AMD-K6, all other machines with CPUs with limited special instruction
sets (Pentium-S, AMD Geode) are working fine.
Closed by Andreas Baumann
31.01.2019 13:50
Reason for closing: Fixed
Additional comments about closing:
31.01.2019 13:50
Reason for closing: Fixed
Additional comments about closing:
works with glibc-2.28-5.5-i486
happens on a Pentium-S now too.
Pentium-II is still fine, so is AMD Geode..
Finally got around to tackle this one
installing a minimal chroot with:
Then debugging the chroot call:
yields:
So, we got cmov creeping in.
/proc/cpuinfo tells us that neither early Pentiums nor AMD K6 had a CMOV opcode.
Now the trick question is, why is it creeping into the C library?
Is the C library compiled with the wrong flags?
Is the gcc assuming that every CPU has a CMOV instruction? Are flags wrong there
or is CMOV suddenly the default?
Checking in glibc: this is the offending opcode
Now the question is, why does glibc think it's ok to use i686 optimizations
when compiling with -march-i486.
Not found an obvious reason, retriggering rebuild on known-good (hopefully) i486 build slave.
config.log shows me i686 as build host. This is guessed with config.guess.
Manually executing config.guess on the build machine results in i486-pc-linux-gnu.
setarch i486 ./config.guess results in i686-pc-linux-gnu.
setarch i486 uname -m results in i686.
This breaks every build on i486!
/usr/bin/setarch is owned by util-linux 2.33.1-2.3 and is is completly broken!
And of course, it's used in setarch "${arch}" mkarchroot in staging-i486-build.
So the consequenses are:
- devtools32 must NOT use setarch anywhere in the *i486* files
- the whole i486 toolchain and all packages have to be rebuilt (basically from the stage of last bootstrapping, every package above could contain bad opcodes!).
The irony is, that building just with makepkg on a emulated i486 virtual machine works
fine, using the devtools breaks things..
Actually, thinking about it: I should try to patch setarch in coreutils for i486.
So we don't have to fork devtools32 too much from upstream..
binutils and gcc have an explicit host and build flags, so they should be fine.
Maybe rebuilding just glibc with a fixed setarch is sufficient.
If we are unlucky, utsname information in setarch.c is wrong and it's not
a coreutils problem..
The man page of setarch documents the bug:
So, we are not allowed to fix this, as other programs may rely on the bug.
So, fixing the devtools32 it is...
setarch bug reported here:
https://github.com/karelzak/util-linux/issues/707
and here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=506632
uname -p reports unknown, this explains why config.guess relies
on uname -m to guess the CPU.
We came to those possible solutions:
- fix setarch.c (rather let it report something different than what the kernel is providing)
- add flags to devtools32 to switch off setarch usage (means, we can no longer build i486 on x86_64 slaves)
- add –build=i486-pc-linux-gnu in every configure call necessary
- go with the CLFS uname hack
- hack setarch of the host machine
The CLFS uname hack solution.
http://trac.clfs.org/ticket/146
http://clfs.org/view/svn/ppc/chroot/before-chroot.html
Ok, the uname hack no longer works, or setarch doesn't rely on this module information.