[Bug 3533] [IcedTea8] HotSpot generates code with unaligned stack, crashes on SSE operations

[bugzilla-daemon at icedtea.classpath.org]

https://icedtea.classpath.org/bugzilla/show_bug.cgi?id=3533

--- Comment #38 from Maciej S. Szmigiero <mail at maciej.szmigiero.name> ---
> Have you recompiled other libraries with -mstackrealign?
> I believe at least glibc needs this as well, if you're building with SSE.

If one recompiles the whole system with "-mstackrealign" (including
non-C/C++ code, too) AND all library-exported functions using SSE that are
written in assembly have the stack pointer realignment prologue manually
added to them then the resulting binaries might work without adding
"-mincoming-stack-boundary=2" flag to the JVM build.

At minimum, one would need to make a list of every library called from
generated JVM code (including every one that might later be called via JNI).
Then, for every library in this list, add its library dependencies to
the list, too.
Repeat the step above until every transitive library dependency is on the list.
Then just these libraries would need to be recompiled with "-mstackrealign"
and have their parts written in assembly checked and fixed as necessary.

Such list would need to be rechecked every time a new library version is
released, so it would be a pretty time consuming and also a fragile method.
One would need to know upfront which libraries future JNI code is going
to use, too.

This list would include glibc for sure, as you mentioned in your comment.
If you recompile glibc with "-mstackrealign" to add stack pointer realignment
prologues to some functions then every program in the system that uses them
(not just JVM) would pay performance penality because of this.
Even the 99.9% of programs and libraries that don't generate code that
misalign the stack.

Ditto for other libraries from the list.
That, is the whole system would pay performance penality because JVM
generates non-standards-conforming code.

Considering this, I think building just JVM with
"-mincoming-stack-boundary=2" is simply a more sensible option (as long
the code generator in it can't be fixed of course).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20190313/fd818ffe/attachment.html>