Segfault in glibc in __fstatat64_time64 called from stat (Gentoo) about 123elf

[vrza]

This old System V/386 code uses 4 byte stack alignment (i.e. stack pointer is incremented and decremented in multiples of 4 bytes).

We're linking it dynamically to libc and ncurses. If host libc and ncurses use some SSE instructions in their compiled code (which will be the case on all modern mainstream OSs), these instructions expect 16 byte stack alignment.

The old System V/386 code might leave the stack aligned to a multiple of 4 bytes that's not a multiple of 16 bytes at some point before jumping into glibc or ncurses, which will cause a segfault.

There are a couple ways to make this old code work on a modern system:

• use -mstackrealign when compiling libc and ncurses for the system 123elf will run on. Some distributions do this for 32-bit versions of libraries. This flag will make the compiler generate extended function prologues and epilogues that will check stack alignment on each function call and allign it to 16 bytes if necessary.

• statically link 123elf with versions of libc and ncurses that were either compiled (a) without instructions that require 16 byte alignment (and so are fine with 4 byte aligned stack),, e.g. -march=i386 or (b) with -mstackrealign. While statically linking against glibc seems to be generally discouraged, as glibc might still dynamically dlopen some shared objects, it is possible that the subset of libc functionality needed by 123elf might be safe.

[vrza]

Recompiling 32-bit glibc with -mstackrealign solved the issue for me. I found some pointers on this here and here.

This glibc stack alignment issue might be worth mentioning in the README.

It might also be worth adding -ltinfo to LDLIBS in the Makefile.

[voyageur]

It might also be worth adding -ltinfo to LDLIBS in the Makefile.

It may depend on how ncurses was compiled (even in Gentoo depending on USE flags), I just changed the line to use pkg-config:
LDLIBS := $(shell pkg-config --libs ncurses)

-mstackrealign did the trick, I did have to add it to 32bit CFLAGS for both glibc and ncurses (adding it only to glibc showed a later segfault in ncurses)

% cat /etc/portage/package.env/32bitstackalign
sys-libs/glibc 32bitstackalign.conf
sys-libs/ncurses 32bitstackalign.conf
% cat /etc/portage/env/32bitstackalign.conf   
CFLAGS_x86="${CFLAGS_x86} -mstackrealign"
CXXFLAGS_x86="${CXXFLAGS_x86} -mstackrealign"

[taviso]

Does this still reproduce?

I'm not sure if I should add -mstackrealign, or if this can only be changed by recompiling ncurses?

[taviso]

Thanks for the discussion, I think I'll close this bug for now and we'll discuss if we should provide a statically linked binary in #76.