Summary: | flag-o-matic.eclass strip-flags/strip-unsupported-flags should not filter out -mstackrealign | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Huss <michaelhuss0> |
Component: | Eclasses | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | mmk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=592222 https://bugs.gentoo.org/show_bug.cgi?id=616402 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Michael Huss
2019-02-13 08:39:15 UTC
(In reply to Michael Huss from comment #0) > Other distros like Ubuntu override GCC's default stack alignment to 4-bytes. > This means that some binaries compiled for those other distros are liable to > segfault on Gentoo boxes due to stack alignment issues. I'm pretty sure distros do not do that. It's an x86 ABI violation. There used to be a time when gcc did not do 16-byte stack alignment. Now it always does. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496#c9 But ancient binaries still exist. > I encountered this > problem playing games from Steam, but it may also occur with other foreign > binaries (and anecdotally with Windows binaries on wine). I think it's a wine bug not to add explicit realignment for each potential transitions from PE land to ELF land. Usually it's just a matter of sprinkling a few attributes like: https://gitweb.gentoo.org/repo/gentoo.git/tree/games-emulation/zsnes/files/zsnes-1.51-stack-align-v2.patch But I totally understand it's a hard surface to cover. > This can be worked around by building certain programs like wine, libxcb, > and glibc with the -mstackrealign cflag. However, the glibc ebuilds use > flag-o-matic's strip functions, and one of them is removing -mstackrealign. > I've used a modified glibc ebuild to append the flag, and I'm able to play > Borderlands 2 now, but a more permanent solution would be for the eclass to > allow future -mstackrealign builds without my treachery. > Notice that I'm not filing against glibc itself, because this flag-append > hack does not completely solve the problem, nor is it applicable to all > users/systems. The proper fix would be for the eclass to allow the *option* > of building with -mstackrealign across the board, at the user's discretion. We can whitelist -mstackrealign for filter-cflags. It should be a safe option. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2004d466896f9b81452c7bdac1ee00866b8f0ff1 commit 2004d466896f9b81452c7bdac1ee00866b8f0ff1 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-02-13 21:01:27 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-02-13 21:03:30 +0000 flag-o-matic.eclass: whitelist -mstackrealign for 'strip-flags' Allow '-mstackrealign' in ebuilds like glibc to force stack realignment. That will allow running ancient (or foreign) binaries that don't maintain 16-byte stack alignment. See bug #677852 for example. Reported-by: Michael Huss Closes: https://bugs.gentoo.org/677852 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/flag-o-matic.eclass | 7 +++++++ 1 file changed, 7 insertions(+) |