please specify or formalize the relationship of r7 as the frame pointer in thumb about abi-aa

[smithp35]

The 2019Q4 release (published in January 2020) has information on the use of r11 and the frame chain. There is a link in the change history to the new sections. I'm not aware of any further unpublished changes.

https://developer.arm.com/docs/ihi0042/i/procedure-call-standard-for-the-arm-architecture-abi-2019q4-documentation

[nickdesaulniers]

on the use of r11 and the frame chain.

Right, but what about r7/THUMB2?

via: https://lore.kernel.org/lkml/[e-mail]/

Historically the frame pointer in Thumb has not been defined in the
AAPCS with implementations falling back to historic definitions of
fp = r7 in Thumb and fp = r11 in Arm.

But now were adding changes to LLVM to warn/error on the use of r7 in THUMB when frame pointers are not omitted, ex:

1. https://reviews.llvm.org/D76848
2. https://reviews.llvm.org/D49727
3. https://reviews.llvm.org/D51165

But the official documents from ARM don't document this relationship at all.

I'm not aware of any further unpublished changes.

Ah, got it, so I misunderstood your LKML post. I had assumed this was addressed in an unpublished version. So I should change the request to: "please specify or formalize the relationship of r7 as the frame pointer in thumb."

[smithp35]

I think the idea is that we want to formalize the frame pointer as r11 going forward.

Prior to the most recent AAPCS the frame pointer register was unspecified and different compilers did different things:
gcc and clang use r7 for Thumb and Thumb2, r11 for Arm
armcc (Arm's proprietary/legacy compiler) used r11 if Thumb2 was available r7 if only Thumb, r11 for Arm.

In a future version of gcc and clang implements r11 as the frame pointer and the errors for using r7 can go away as it will no longer be the frame-pointer.

The place for documenting the current use of r7 as the frame-pointer would be the GCC and Clang documentation as prior to the recent ABI update it was implementation defined.

prior to the most recent AAPCS there was no

[nickdesaulniers]

My understanding of the
AAPCS is that it has been changed to make the frame pointer r11 on
both Arm and Thumb to make unwinding possible

it is likely some platforms will want to persist
with r7.

oh, sorry, so I misunderstand yet again. r7 is the "legacy frame pointer" and r11 is the "new" frame pointer on thumb?

I see in LLVM getFramePointerReg can return r7 or r11...based on

  bool useR7AsFramePointer() const {
    return isTargetDarwin() || (!isTargetWindows() && isThumb());
  }

[smithp35]

Yes, that's correct. I'm not sure what returning r11 on a target without Thumb 2 would do (not a problem for Darwin and Windows). With luck it would just work, but would need to do some testing.

[nickdesaulniers]

So that logic in LLVM looks wrong then to me (or at least out dated in terms of changes to AAPCS). What's the plan for changing that logic?

[TNorthover]

Yeah, Apple still uses r7 as the frame pointer. The main affected platform is 32-bit watches, which are still in circulation.

That ABI is AAPCS-based, but not exactly the same (stack alignment is 16 bytes for example). I don't think we plan to change any of that, and if we've already got divergence from AAPCS one more change doesn't really matter anyway.

[smithp35]

I'll need to check with @kbeyls and the internal engineering teams at Arm with respect to changing to r11 in clang and gcc, obviously we'll need to preserve other platforms choices.