- Status Closed
- Percent Complete
- Task Type Bug Report
- Category Packages
-
Assigned To
Erich Eckner - Operating System i486
- Severity Low
- Priority Medium
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Arch Linux 32
Opened by Andreas Baumann - 01.05.2021
Last edited by Andreas Baumann - 19.02.2022
Opened by Andreas Baumann - 01.05.2021
Last edited by Andreas Baumann - 19.02.2022
FS#186 - [pacman] /etc/makeconf.conf for i486 contains flags resulting to ILLEGAL INSTRUCTION
-fstack-clash-protection
-fcf-protection
We have to investiagate if one of them (or both) are
introducing illegal opcodes for i486..
It's -fcf-protection, which adds endbr32 opcodes. We have to disable this on
486 completely. On i686 we can keep it (as the microcode of those CPUs is
changing them to multi-byte NOPs).
-fstack-clash-protection is just fine also for i486.
This has to be patched in the i486 patching of pacman32..
sounds, like we should remove -fcf-protection for i486 *and* i686, while we're at it.
another question: does it make a difference on pentium4?
Because, if it does not, the easiest way would be to skip this option on *all* architectures in our makepkg.conf
I'll removed the flag completely (for now):
https://git.archlinux32.org/packages/commit/?id=80ef7a5b40d993d25f13d0767c912d8c7276dc9b
If you think, it's worth keeping it on pentium4, then I can commit a more elaborate patch which only removes it on i486 and i686.
Could be that CET is available on some really modern 32-bit Intels,
so one could think of benefit on pentium4 maybe..
ok, so it would make sense to ship one makepkg.conf for each architecture (we patch the architecture, currently, anyways)
I don't have the best feeling to change this on i486 build slaves
in mid-air..
That's quite some flags, do they come from upstream?
In my experience, if you change any of those, you have to rebuild the
toolchain and _all_ packages..
I just update eurobuild3-i486 and then see if we get broken packages.
I have a hunch that python, cython segfaults are the result of fiddling
with flags..
no problem there: the build slaves use devtools32, which ship their own makepkg.confs. I added some lines to the Makefile there, to get rid of -fstack-clash-protection if I rebase onto upstream changes including this option.
on a qemu-i486-slave, no problem on the 64-bit host with staging-i486-build.
(the package is gdal)
this is during build of gdal? Or is this during using the packaged gdal?
During building of gdal.
But the pointers go to python, cython, swig, python-numpy, etc.
It's not clear to me, why python segfaults. I rebuilt puthon,
C-bindings, so I can pretty much rule that one one, swig generates
code, so I doubt it to be the problem. Currently I'm digging
through python-numpy and it's SIMD optimization flags..
shouldn't any debugger tell you, in which program the stack smashing happens? But since you're more the expert on these things, I believe it's not that simple
Aha, I also get the same problem with pentium4, so it cannot be the flag changes for i486
above.. so I suspect we have a general numpy problem (also seen with some library needed
by blender).
Yes, I see vector operations and numpy in the stack trace of the stack smash when
building swig Python binaries.