llvm dev - Jul 2014 - [LLVMdev] GCC/LLVM frame pointer incompatibility on ARM

Hi all,

As has been mentioned several times (*), LLVM and GCC setup frame 
pointer to point to different stack slots on ARM. GCC's fp points to 
stack slot holding lr while LLVM's fp points at the next slot.

Fp incompatibility complicates low-level system code e.g. stack 
unwinders because it is impossible to robustly determine location of 
caller's fp.

Is this incompatibility intentional/desired or we could somehow unify 
GCC and LLVM in this regard?

(*) Links to older discussions:
* http://comments.gmane.org/gmane.comp.compilers.llvm.devel/69514
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771

--
Best regards,
Yury Gribov

On Wed, Jul 16, 2014 at 09:45:05AM +0400, Yury Gribov
wrote:
> Fp incompatibility complicates low-level system code e.g. stack
> unwinders because it is impossible to robustly determine location of
> caller's fp.
I don't understand this argument. The ARM EH / DWARF annotation is
supported by LLVM and encodes exactly the data required for robustly
unwinding the stack.

Joerg

On Wed, Jul 16, 2014 at 11:10 AM, Joerg Sonnenberger
<joerg at britannica.bec.de> wrote:
> On Wed, Jul 16, 2014 at 09:45:05AM +0400, Yury Gribov wrote:
>> Fp incompatibility complicates low-level system code e.g. stack
>> unwinders because it is impossible to robustly determine location of
>> caller's fp.
>
> I don't understand this argument. The ARM EH / DWARF annotation is
> supported by LLVM and encodes exactly the data required for robustly
> unwinding the stack.
Not fast enough for us.
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

> As has been mentioned several times (*), LLVM and GCC setup frame pointer
to
> point to different stack slots on ARM. GCC's fp points to stack slot
holding
> lr while LLVM's fp points at the next slot.
This looks flipped from my tests. Both create an { fp, lr } struct;
GCC sets current fp to the address of lr in that struct; LLVM sets
current fp to the address of fp in that struct.
> Is this incompatibility intentional/desired or we could somehow unify GCC
> and LLVM in this regard?
What are the chances of getting GCC to change here? It's entirely a
bike-shedding argument, but there are a couple of reasons to prefer
LLVM's choice. It's most consistent with what *is* required in the
AArch64 ABI, and it means fp really points to the frame record, not
some random point half way through it.

Cheers.

Tim.

On 16 July 2014 08:45, Tim Northover <t.p.northover at gmail.com>
wrote:
> What are the chances of getting GCC to change here? It's entirely a
> bike-shedding argument, but there are a couple of reasons to prefer
> LLVM's choice. It's most consistent with what *is* required in the
> AArch64 ABI, and it means fp really points to the frame record, not
> some random point half way through it.
I'm not an expert in x86_64 asm, but it seems that both AArch64 and
x86_64 GCC do the same:

x86_64:
pushq %rbp
movq %rsp, %rbp
subq $16, %rsp

AArch64:
stp x29, x30, [sp, -32]!
add x29, sp, 0

which would indicate that LLVM's implementation on ARM is the most
consistent. I'm guessing ARM GCC's implementation was not an accident,
but a long forgotten hack... :/

cheers,
--renato

On Wed, Jul 16, 2014 at 11:45 AM, Tim Northover <t.p.northover at
gmail.com> wrote:
>> As has been mentioned several times (*), LLVM and GCC setup frame
pointer to
>> point to different stack slots on ARM. GCC's fp points to stack
slot holding
>> lr while LLVM's fp points at the next slot.
>
> This looks flipped from my tests. Both create an { fp, lr } struct;
> GCC sets current fp to the address of lr in that struct; LLVM sets
> current fp to the address of fp in that struct.
>
>> Is this incompatibility intentional/desired or we could somehow unify
GCC
>> and LLVM in this regard?
>
> What are the chances of getting GCC to change here? It's entirely a
> bike-shedding argument, but there are a couple of reasons to prefer
> LLVM's choice. It's most consistent with what *is* required in the
> AArch64 ABI, and it means fp really points to the frame record, not
> some random point half way through it.
It is also consistent with x86: we use exactly the same code to unwind
stack on both platforms.
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

On 07/16/2014 11:45 AM, Tim Northover wrote:
>>> As has been mentioned several times (*), LLVM and GCC setup frame
pointer to
>> point to different stack slots on ARM. GCC's fp points to stack
slot holding
>> lr while LLVM's fp points at the next slot.
>
> This looks flipped from my tests. Both create an { fp, lr } struct;
> GCC sets current fp to the address of lr in that struct; LLVM sets
> current fp to the address of fp in that struct.
Right, I misread the assembly :(
>> Is this incompatibility intentional/desired or we could somehow unify
GCC
>> and LLVM in this regard?
>
> What are the chances of getting GCC to change here?
Well, their logic is that as long as FP is not part of ARM ABI they can 
make arbitrary choice
even if it complicates user's life. I really hope that Renato could 
persuade people that
this is worth changing.
> It's entirely a
> bike-shedding argument, but there are a couple of reasons to prefer
> LLVM's choice. It's most consistent with what *is* required in the
> AArch64 ABI, and it means fp really points to the frame record, not
> some random point half way through it.
Yeah, I think everyone agrees on this.

-Y