• Status Assigned
  • Percent Complete
    0%
  • 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 - 01.05.2021

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..

Admin
Andreas Baumann commented on 01.05.2021 08:45

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..

Admin
Erich Eckner commented on 01.05.2021 10:46

sounds, like we should remove -fcf-protection for i486 *and* i686, while we're at it.

Admin
Erich Eckner commented on 01.05.2021 10:48

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

Admin
Erich Eckner commented on 01.05.2021 10:58

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.

Admin
Andreas Baumann commented on 01.05.2021 13:15

Could be that CET is available on some really modern 32-bit Intels,
so one could think of benefit on pentium4 maybe..

Admin
Erich Eckner commented on 01.05.2021 13:20

ok, so it would make sense to ship one makepkg.conf for each architecture (we patch the architecture, currently, anyways)

Admin
Andreas Baumann commented on 01.05.2021 14:15

I don't have the best feeling to change this on i486 build slaves
in mid-air..

CFLAGS="-march=i486 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2,-D_GLIBCXX_ASSERTIONS \
        -Wformat -Werror=format-security \
        -fstack-clash-protection"

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..

Admin
Erich Eckner commented on 03.05.2021 03:41

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.

Admin
Andreas Baumann commented on 05.05.2021 14:37
*** stack smashing detected ***: terminated
/startdir/PKGBUILD: line 93:  6807 Aborted                 (core dumped) python setup.py build

on a qemu-i486-slave, no problem on the 64-bit host with staging-i486-build.
(the package is gdal)

Admin
Erich Eckner commented on 06.05.2021 14:56

this is during build of gdal? Or is this during using the packaged gdal?

Admin
Andreas Baumann commented on 06.05.2021 15:57

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..

Admin
Erich Eckner commented on 06.05.2021 16:33

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 :-)

Admin
Andreas Baumann commented on 06.05.2021 17:05

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.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing