On Tue, Dec 14, 2021 at 12:21 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
>
> * Manuel Lauss:
>
> > On Mon, Dec 13, 2021 at 2:04 PM Florian Weimer <fweimer@xxxxxxxxxx> wrote:
> >>
> >> * Manuel Lauss via Gcc-help:
> >>
> >> > Now the descriptions of "vmovdqa" I could find say that it generates a
> >> > #GP when the destination is not 16-byte aligned. Does this alignment
> >> > include the displacement, like above? If yes, is this then a code
> >> > generation bug in gcc?
> >>
> >> If your build uses vector instructions, you need to build glibc with
> >> -mstackrealign for compatibility with legacy i386 applications.
> >
> > I read that gcc-12 enables "-ftree-vectorize" with -O2 by default, and
> > indeed a glibc snapshot built with gcc-12 and "-O2 -march=haswell"
> > suffers now from the same problem. Should "-mstackrealign" be added
> > to 32bit x86 build unconditionally?
>
> I think it's just something you need to know when building glibc for
> legacy applications. Most users will likely prefer full optimization
> for their builds (otherwise they wouldn't build with -march=haswell).
Is there an explanation of how this whole stack magic works? I wrote
a small test for dlvsym() and its stack pointer is precisely
aligned so that the vmovdqa with displacement 0xc points to a 16-byte
aligned address. However I don't get how the failing program gets its
misaligned stack. Does it have to be built with special compiler flags or
linker scripts?
Thanks!
Manuel
