View Issue Details

IDProjectCategoryView StatusLast Update
0032710FPCCompilerpublic2017-12-05 21:01
ReporterDaniel Glöckner Assigned ToJonas Maebe  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionduplicate 
Platformi386OSLinux 
Product Version3.1.1 
Summary0032710: Compiler should use stackalign=16 on x86-32
DescriptionGCC on Linux x86-32 nowadays assumes the stack is aligned to 16 bytes. The alignment has been documented in a supplement to the ABI (Section 2.2.2 of https://www.uclibc.org/docs/psABI-i386.pdf).

Failing to align the stack will cause crashes when an external function is called that stores an SSE value in a stack variable.
Additional InformationSomeone else also had this problem a few years ago:
http://forum.lazarus.freepascal.org/index.php?topic=29097.0
TagsNo tags attached.
Fixed in Revision
FPCOldBugId
FPCTarget
Attached Files

Relationships

duplicate of 0015582 resolvedFlorian "-OaLOCALMIN=16" / "codealign LOCALMIN=16" is not reliable 

Activities

Daniel Glöckner

2017-11-19 16:43

reporter  

i386-linux-stackalign.patch (595 bytes)   
--- compiler/systems/i_linux.pas.orig	2017-11-19 16:28:37.231687061 +0100
+++ compiler/systems/i_linux.pas	2017-11-19 16:30:37.324282568 +0100
@@ -93,7 +93,7 @@
               );
             first_parm_offset : 8;
             stacksize    : 8*1024*1024;
-            stackalign   : 4;
+            stackalign   : 16;
             abi : abi_default;
             { note: default LLVM stack alignment is 16 bytes for this target }
             llvmdatalayout : 'e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32';
i386-linux-stackalign.patch (595 bytes)   

Thaddy de Koning

2017-11-20 08:27

reporter   ~0104196

Last edited: 2017-11-20 08:43

View 2 revisions

{$CODEALIGN LOCALMIN=16}

Is already in place. And does what you want.
Maybe it can be a default.
I am not sure if your patch can break existing code.

Martok

2017-11-23 17:39

reporter   ~0104233

Thaddy, you are wrong. {$CODEALIGN LOCALMIN} does exactly what it says on the tin. tsysteminfo.stackalign is an ABI property.

Ideally, you will have stackalign=16 to be able to be able to call functions from other compilers, while packing your own local variables on a different (smaller) grid. Your solution provides a workaround until this is fixed, but occupies up to 4x more stackspace.

Thaddy de Koning

2017-11-24 10:21

reporter   ~0104237

Last edited: 2017-11-24 10:22

View 2 revisions

So you are actually saying I am right? "Your solution provides a workaround until this is fixed, but occupies up to 4x more stackspace."
That's always the case with stack alignment.....
It is not a workaround. It has the exact same effect as the patch.

Daniel Glöckner

2017-11-25 11:44

reporter   ~0104254

I recompiled the application with -OaLOCALMIN=16 but the problem persists.

LOCALMIN=16 changes the lea instruction in the prologue to subtract a multiple of 16 bytes from esp. But doing so it does not take the following things into account:
 - The call instruction pushes the return address on the stack
 - The function's own push instructions to save registers
 - Parameters pushed on the stack to call the next function

So LOCLAMIN is broken and does not enforce a higher alignment for stack variables. All it does is enforce a higher relative alignment between variables of the same function, which is useless.

Issue History

Date Modified Username Field Change
2017-11-19 16:43 Daniel Glöckner New Issue
2017-11-19 16:43 Daniel Glöckner File Added: i386-linux-stackalign.patch
2017-11-20 08:27 Thaddy de Koning Note Added: 0104196
2017-11-20 08:43 Thaddy de Koning Note Edited: 0104196 View Revisions
2017-11-23 17:39 Martok Note Added: 0104233
2017-11-24 10:21 Thaddy de Koning Note Added: 0104237
2017-11-24 10:22 Thaddy de Koning Note Edited: 0104237 View Revisions
2017-11-25 11:44 Daniel Glöckner Note Added: 0104254
2017-12-05 21:01 Jonas Maebe Relationship added duplicate of 0015582
2017-12-05 21:01 Jonas Maebe Status new => resolved
2017-12-05 21:01 Jonas Maebe Resolution open => duplicate
2017-12-05 21:01 Jonas Maebe Assigned To => Jonas Maebe