Opened 11 years ago
Closed 11 years ago
#1994 closed defect (fixed)
"Illegal instruction" when running binaries/system/test on amd64
| Reported by: | Vincent Cheng | Owned by: | |
|---|---|---|---|
| Priority: | Should Have | Milestone: | Alpha 15 |
| Component: | Build & Packages | Keywords: | |
| Cc: | Jan Wassenberg, Josh | Patch: |
Description
Forwarded from Debian's BTS: #712956
0ad fails to build on one of Debian's amd64 build machines, because it errors out when running binaries/system/test ("Illegal instruction"); see build log here. Is it possible that premake (or something else) is injecting certain flags or causing gcc to build 0ad with certain optimizations not universally supported on amd64? I see -msse in the build log, but that should be fine on amd64 (AFAIK amd64 guarantees at least SSE2 support). Could premake be hiding some of the compiler output (even though verbose build is enabled)?
FWIW, the amd64 build machine on which this occurred is barber.debian.org (Dell PowerEdge 1855).
On another note, the i386 build log shows that 0ad is being built with -msse and -march=i686, but that's problematic for Debian given that Debian's "i386" architecture targets i486, not i686. Is it possible for 0ad to be built and run on i486 and without -msse?
Change History (18)
follow-up: 3 comment:1 by , 11 years ago
follow-up: 4 comment:2 by , 11 years ago
Could it be caused by this bug in NVTT: #1894? The Debian libnvtt package doesn't appear to have a patch applied for that.
About -march=i686, there's a comment in premake4.lua:
-- To support intrinsics like __sync_bool_compare_and_swap on x86 -- we need to set -march to something that supports them
comment:3 by , 11 years ago
Replying to Markus:
Does it also happen in debug build? Can you try running it in gdb? (Unfortunatelly the test file is quite big and the illegal instruction might not show up on a different machine.)
i486 should™ work by modifing the premake4.lua file. (Set arch to i486 and remove sse)
(You can build with
make SHELL="/bin/bash -x" ...to see every executed command.)
It doesn't happen in debug build on my local machine either. Not being able to reproduce this on my own Debian system is definitely making this much harder to debug...
follow-up: 9 comment:4 by , 11 years ago
Replying to historic_bruno:
Could it be caused by this bug in NVTT: #1894? The Debian libnvtt package doesn't appear to have a patch applied for that.
Ah, that might be the cause. I'll try to get that patch included in Debian's nvtt package, thanks! Incidentally, are there any other patches in 0ad's internal copy of nvtt that should also be applied in Debian?
About
-march=i686, there's a comment in premake4.lua:-- To support intrinsics like __sync_bool_compare_and_swap on x86 -- we need to set -march to something that supports them
Ack, so leave it be and don't force -march=i486.
comment:5 by , 11 years ago
Kurt Roeckx made the following comment on Debian bug #712956, which I'll quote here:
Using -march is almost always the wrong thing to do in Debian. This really should only be used if there is an other way to not i686 specific code.
Please note that the function they say they need are now marked as legacy, see http://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync http://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
Is that comment in premake4.lua still relevant? It looks like it's been in that file since rev 8526, from 3 years back...
comment:6 by , 11 years ago
| Cc: | added |
|---|
I don't know about alternatives, but we certainly still use __sync_bool_compare_and_swap, see source/lib/sysdep/arch/ia32/ia32.cpp.
CC'ing Jan, he would know all about that code.
comment:7 by , 11 years ago
We wouldn't run on an actual 486 due to use of several newer CPU instructions, one of which is the CAS in ia32.cpp. If indeed we have to compile with -march=i486, which sounds like a last resort, the CAS could be replaced with GCC-specific assembly, and we'd have a decent hope of compiling successfully.
comment:8 by , 11 years ago
I see, thanks for the explanation! This is beyond my knowledge, but should at least be sufficient rationale for me not to touch -march in premake4.lua.
follow-up: 11 comment:9 by , 11 years ago
Replying to vincent:
Replying to historic_bruno:
Could it be caused by this bug in NVTT: #1894? The Debian libnvtt package doesn't appear to have a patch applied for that.
Ah, that might be the cause. I'll try to get that patch included in Debian's nvtt package, thanks! Incidentally, are there any other patches in 0ad's internal copy of nvtt that should also be applied in Debian?
Don't think so, we keep a list of them in libraries/source/nvtt/README.txt.
(And for reference: #713966 nvidia-texture-tools: OptimalOptions.cmake assumes x86_64 implies athlon64)
comment:10 by , 11 years ago
| Milestone: | Backlog → Alpha 14 |
|---|
follow-up: 12 comment:11 by , 11 years ago
Replying to historic_bruno:
Replying to vincent:
Incidentally, are there any other patches in 0ad's internal copy of nvtt that should also be applied in Debian?
Don't think so, we keep a list of them in libraries/source/nvtt/README.txt.
The recent arm fix patch will enable to build nvtt on arm. 0ad alpha14 also will build on arm.
comment:12 by , 11 years ago
Replying to fabio:
The recent arm fix patch will enable to build nvtt on arm. 0ad alpha14 also will build on arm.
May you please link me to the patch that fixes nvtt build on arm? I'd like to have that added to the nvtt packages in Debian and Ubuntu.
follow-up: 14 comment:13 by , 11 years ago
| Cc: | added |
|---|
It's the arm-fix from there: http://trac.wildfiregames.com/browser/ps/trunk/libraries/source/nvtt/patches
Also since the last time I pinged Lennart there is a clang build fix (issue182 patch) and cmake-noqt4 (I think this will disable building with QT4 even when its dev libs are found, to have a consistent build).
Adding Josh in CC, he wrote some of the patches.
follow-up: 15 comment:14 by , 11 years ago
Replying to fabio:
It's the arm-fix from there: http://trac.wildfiregames.com/browser/ps/trunk/libraries/source/nvtt/patches
Also since the last time I pinged Lennart there is a clang build fix (issue182 patch) and cmake-noqt4 (I think this will disable building with QT4 even when its dev libs are found, to have a consistent build).
Adding Josh in CC, he wrote some of the patches.
Thanks! And just to be sure, does this patch enable compilation on armel, armhf, or both? (i.e. soft-float vs hard-float ABI)
comment:15 by , 11 years ago
Replying to vincent:
Replying to fabio :
It's the arm-fix from there: http://trac.wildfiregames.com/browser/ps/trunk/libraries/source/nvtt/patches Also since the last time I pinged Lennart there is a clang build fix (issue182 patch) and cmake-noqt4 (I think this will disable building with QT4 even when its dev libs are found, to have a consistent build). Adding Josh in CC, he wrote some of the patches.
Thanks! And just to be sure, does this patch enable compilation on armel, armhf, or both? (i.e. soft-float vs hard-float ABI)
I see no reason why my patch wouldn't work on both platforms, but I've only tested on armhf.
comment:16 by , 11 years ago
| Milestone: | Alpha 14 → Alpha 15 |
|---|
comment:17 by , 11 years ago
Debian nvtt since 2.0.8-1+dfsg-4 disable -march=athlon64. Also it successfully builds on arm: http://ftp-master.metadata.debian.org/changelogs//main/n/nvidia-texture-tools/nvidia-texture-tools_2.0.8-1+dfsg-4_changelog
Does it also happen in debug build? Can you try running it in gdb? (Unfortunatelly the test file is quite big and the illegal instruction might not show up on a different machine.)
i486 should™ work by modifing the premake4.lua file. (Set arch to i486 and remove sse)
(You can build with
make SHELL="/bin/bash -x" ...to see every executed command.)