Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#71053 - [openttd] OpenTTD does not run on older CPUs due to use of SSE 4.1 instructions
Attached to Project:
Community Packages
Opened by David Kolossa (yayachiken) - Saturday, 29 May 2021, 16:48 GMT
Last edited by Alexander F. Rødseth (xyproto) - Saturday, 29 May 2021, 21:18 GMT
Opened by David Kolossa (yayachiken) - Saturday, 29 May 2021, 16:48 GMT
Last edited by Alexander F. Rødseth (xyproto) - Saturday, 29 May 2021, 21:18 GMT
|
DetailsDescription:
Using an "AMD Phenom(tm) II X6 1090T Processor", openttd will crash on startup after receiving SIGILL. Running the application under gdb and disassembling the last instruction shows that openttd crashed after encountering the pinsrq instruction from the SSE 4.1 instruction set, which AMD did not support until the Bulldozer architecture (released 2011). I was able to work around that issue by amending the PKGBUILD file. I added CXXFLAGS="-mtune=native" to the cmake call, thus building with the correct instruction set for my machine. Of course, this workaround will not work for pre-built distribution packages, as the buildnodes hopefully have a more capable CPU than I have :) I don't know how the packaging guidelines are. But Phenom II CPUs are not that old (~10 years), and OpenTTD is not that much of a high-end game, so I would expect it to work. Additional info: * package version: openttd 1.11.2-2 Steps to reproduce: * On a machine with an AMD Phenom II CPU run gdb openttd * openttd will crash on startup * Enter the gdb command bt to get the backtrace * disassemble the executable in the vincinity of the last instruction, for me that showed (gdb) disassemble 0x0000555555af3266,0x0000555555af3270 Dump of assembler code from 0x555555af3266 to 0x555555af3270: => 0x0000555555af3266: pinsrq $0x1,%rbp,%xmm0 0x0000555555af326d: movups %xmm1,0x10(%rbx) End of assembler dump. 
crash.log
(3.4 KiB)
|
This task depends upon
This change on a system that does have SSE4 disables the check and prevents its use.
sed -i 's/SSE_FOUND/DISABLE_SSE_FOUND/' $pkgname-$pkgver/cmake/FindSSE.cmake
[1] https://github.com/OpenTTD/OpenTTD/blob/1.11.2/cmake/FindSSE.cmake#L16
[2] https://github.com/OpenTTD/OpenTTD/blob/1.11.2/src/blitter/CMakeLists.txt#L42
I cannot confirm that behaviour.
I actually tried just rebuilding the package first with no changes. But without the change to CXXFLAGS that I mentioned, I just built a package with the identical problem.
Not sure I understand exactly how the test should work, compiling with -msse4.1 can be performed on any host.
Edit:
I missed FindSSE.cmake only checks what the compiler supports. There is nothing in the code to limit support to what the host or a target can support, should that be less than that of the compiler.
I removed all lines with 'sse' or 'SSE' from CMakeLists.txt and rebuilt with -D CMAKE_CXX_FLAGS=' -mtune=generic'.
objdump -d of the executable looks promising.
I updated the package in [community].
Please confirm that it's now working as expected.
Could you drop the above as it is not required to fix the issue and removes Arch's hardening flags?
Edit:
It changes CXXFLAGS from '-march=x86-64 -mtune=generic -O2 -pipe -fno-plt' to ' -mtune=generic' it does not change -mtune=generic