[GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Srinath Parvathaneni via Gcc-patches]

Hello,

This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
hard-register and also 
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives 
accordingly.
This patch also adds support to emit ".pacspval" directive when "pac ip, lr, 
sp" instruction
in generated in the assembly.

RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.

Applying this patch on top of PACBTI series posted here
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599658.html and when 
compiling the following
test.c with "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard
fasynchronous-unwind-tables -g -O0 -S" command line options, the assembly 
output after this patch
looks like below:

$cat test.c

void fun1(int a);
void fun(int a,...)
{
  fun1(a);
}

int main()
{
  fun (10);
  return 0;
}

$ arm-none-eabi-gcc -march=armv8.1-m.main+mve+pacbti 
-mbranch-protection=pac-ret -mthumb -mfloat-abi=hard
-fasynchronous-unwind-tables -g -O0 -S test.s

Assembly output:
...
fun:
...
.pacspval
pac ip, lr, sp
.cfi_register 143, 12
push{r3, r7, ip, lr}
.save {r3, r7, ra_auth_code, lr}
...
.cfi_offset 143, -24
...
.cfi_restore 143
...
aut ip, lr, sp
bx  lr
...
main:
...
.pacspval
pac ip, lr, sp
.cfi_register 143, 12
push{r3, r7, ip, lr}
.save {r3, r7, ra_auth_code, lr}
...
.cfi_offset 143, -8
...
.cfi_restore 143
...
aut ip, lr, sp
bx  lr
...

Regression tested on arm-none-eabi target and found no regressions.

Ok for master?

Regards,
Srinath.

2023-01-11  Srinath Parvathaneni  

* config/arm/aout.h (ra_auth_code): Add entry in enum.
(emit_multi_reg_push): Add RA_AUTH_CODE register to
dwarf frame expression.
(arm_emit_multi_reg_pop): Restore RA_AUTH_CODE register.
(arm_expand_prologue): Update frame related information and reg notes
for pac/pacbit insn.
(arm_regno_class): Check for pac pseudo reigster.
(arm_dbx_register_number): Assign ra_auth_code register number in dwarf.
(arm_init_machine_status): Set pacspval_needed to zero.
(arm_debugger_regno): Check for PAC register.
(arm_unwind_emit_sequence): Print .save directive with ra_auth_code
register.
(arm_unwind_emit_set): Add entry for IP_REGNUM in switch case.
(arm_unwind_emit): Update REG_CFA_REGISTER case._
* config/arm/arm.h (FIRST_PSEUDO_REGISTER): Modify.
(DWARF_PAC_REGNUM): Define.
(IS_PAC_REGNUM): Likewise.
(enum reg_class): Add PAC_REG entry.
(machine_function): Add pacbti_needed state to structure.
* config/arm/arm.md (RA_AUTH_CODE): Define.

gcc/testsuite/ChangeLog:

2023-01-11  Srinath Parvathaneni  

* g++.target/arm/pac-1.C: New test.
* gcc.target/arm/pac-15.c: Likewise.


dwarf_pacbti
Description: dwarf_pacbti

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Jakub Jelinek via Gcc-patches]

On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches 
wrote:
> Hello,
> 
> This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
> hard-register and also 
> updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" 
> directives accordingly.
> This patch also adds support to emit ".pacspval" directive when "pac ip, lr, 
> sp" instruction
> in generated in the assembly.
> 
> RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.

I'm afraid increasing number of DWARF registers is ABI incompatible change.
E.g. libgcc __frame_state_for function fills in:
typedef struct frame_state
{
  void *cfa;
  void *eh_ptr;
  long cfa_offset;
  long args_size;
  long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
  unsigned short cfa_reg;
  unsigned short retaddr_column;
  char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
} frame_state;

structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to
__LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange for
PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.

Jakub

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Richard Earnshaw (lists) via Gcc-patches]

On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:

On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via Gcc-patches 
wrote:

Hello,

This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives 
accordingly.
This patch also adds support to emit ".pacspval" directive when "pac ip, lr, 
sp" instruction
in generated in the assembly.

RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.


I'm afraid increasing number of DWARF registers is ABI incompatible change.
E.g. libgcc __frame_state_for function fills in:
typedef struct frame_state
{
   void *cfa;
   void *eh_ptr;
   long cfa_offset;
   long args_size;
   long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
   unsigned short cfa_reg;
   unsigned short retaddr_column;
   char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
} frame_state;

structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to
__LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange for
PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.

Jakub



So where's the red flag that warns about this?

I also note that Richard Sandiford made a similar type of change for 
AArch64 in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and 
nothing was said about that at the time.


It seems incredibly fragile to me to have some ABI based off the number 
of machine registers.


R.

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Richard Earnshaw via Gcc-patches]

On 13/01/2023 21:58, Richard Earnshaw (lists) via Gcc-patches wrote:

On 13/01/2023 18:02, Jakub Jelinek via Gcc-patches wrote:
On Fri, Jan 13, 2023 at 05:44:15PM +, Srinath Parvathaneni via 
Gcc-patches wrote:

Hello,

This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" 
directives accordingly.
This patch also adds support to emit ".pacspval" directive when "pac 
ip, lr, sp" instruction

in generated in the assembly.

RA_AUTH_CODE register number is 107 and it's dwarf register number is 
143.


I'm afraid increasing number of DWARF registers is ABI incompatible 
change.

E.g. libgcc __frame_state_for function fills in:
typedef struct frame_state
{
   void *cfa;
   void *eh_ptr;
   long cfa_offset;
   long args_size;
   long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
   unsigned short cfa_reg;
   unsigned short retaddr_column;
   char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
} frame_state;

structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to
__LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange 
for

PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.

Jakub



So where's the red flag that warns about this?

I also note that Richard Sandiford made a similar type of change for 
AArch64 in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and 
nothing was said about that at the time.


It seems incredibly fragile to me to have some ABI based off the number 
of machine registers.


R.


Also, the Arm port does not use dwarf based unwinding, so is this really 
relevant?


R.

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Jakub Jelinek via Gcc-patches]

On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> > I'm afraid increasing number of DWARF registers is ABI incompatible change.
> > E.g. libgcc __frame_state_for function fills in:
> > typedef struct frame_state
> > {
> >void *cfa;
> >void *eh_ptr;
> >long cfa_offset;
> >long args_size;
> >long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
> >unsigned short cfa_reg;
> >unsigned short retaddr_column;
> >char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
> > } frame_state;
> > 
> > structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to
> > __LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
> > DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
> > So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange for
> > PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.
> > 
> > Jakub
> > 
> 
> So where's the red flag that warns about this?
> 
> I also note that Richard Sandiford made a similar type of change for AArch64
> in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and nothing was said
> about that at the time.
> 
> It seems incredibly fragile to me to have some ABI based off the number of
> machine registers.

It is.  The new unwinder fortunately doesn't suffer from this (at least I
think it doesn't), but in older gccs the unwinder could be split across 
different
objects, having e.g. parts of the unwinder in one shared library and another
part in another one, each built by different GCC version.

Guess targets which weren't supported in GCC 2.x are ok, while
__frame_state_for is in libgcc, nothing calls it, so while such changes
change the ABI, nothing likely cares.
But for older targets it is a problem.

And it is hard to catch this in the testsuite, one would either need to
hardcode the count for each target in the test, or test with mixing GCC 2.x
compiled code with current trunk.

Before the introduction of libgcc_eh.a etc., parts of the unwinder was e.g.
exported from glibc.
See e.g. https://gcc.gnu.org/legacy-ml/gcc-patches/2001-07/threads.html#00472
for some details.

Jakub

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Richard Earnshaw (lists) via Gcc-patches]

On 13/01/2023 22:12, Jakub Jelinek wrote:

On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:

> I'm afraid increasing number of DWARF registers is ABI incompatible change.
> E.g. libgcc __frame_state_for function fills in:
> typedef struct frame_state
> {
>    void *cfa;
>    void *eh_ptr;
>    long cfa_offset;
>    long args_size;
>    long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
>    unsigned short cfa_reg;
>    unsigned short retaddr_column;
>    char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
> } frame_state;
> 
> structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to

> __LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
> DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
> So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you arrange for
> PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.
> 
>  Jakub
> 


So where's the red flag that warns about this?

I also note that Richard Sandiford made a similar type of change for AArch64
in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and nothing was said
about that at the time.

It seems incredibly fragile to me to have some ABI based off the number of
machine registers.


It is.  The new unwinder fortunately doesn't suffer from this (at least I
think it doesn't), but in older gccs the unwinder could be split across 
different

objects, having e.g. parts of the unwinder in one shared library and another
part in another one, each built by different GCC version.

Guess targets which weren't supported in GCC 2.x are ok, while
__frame_state_for is in libgcc, nothing calls it, so while such changes
change the ABI, nothing likely cares.
But for older targets it is a problem.

And it is hard to catch this in the testsuite, one would either need to
hardcode the count for each target in the test, or test with mixing GCC 2.x
compiled code with current trunk.

Before the introduction of libgcc_eh.a etc., parts of the unwinder was e.g.
exported from glibc.
See e.g. 
https://gcc.gnu.org/legacy-ml/gcc-patches/2001-07/threads.html#00472 


for some details.

     Jakub



So:
1) GCC-2.* didn't support the EABI, which is all we support these days.
2) the Arm port updated FIRST_PSEUDO_REGISTER in 2019 in r10-4441 
(16155ccf588a403c033ccd7743329671bcfb27d5) and I didn't see any fallout 
from that.
3) The Arm port uses the unwinding mechanism defined by the ABI, not the 
dwarf2 based tables.


So I'm inclined to think this probably isn't going to be a problem in 
reality.


R.

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Richard Earnshaw via Gcc-patches]

On 13/01/2023 22:25, Richard Earnshaw (lists) via Gcc-patches wrote:

On 13/01/2023 22:12, Jakub Jelinek wrote:

On Fri, Jan 13, 2023 at 09:58:26PM +, Richard Earnshaw (lists) wrote:
> I'm afraid increasing number of DWARF registers is ABI incompatible 
change.

> E.g. libgcc __frame_state_for function fills in:
> typedef struct frame_state
> {
>    void *cfa;
>    void *eh_ptr;
>    long cfa_offset;
>    long args_size;
>    long reg_or_offset[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
>    unsigned short cfa_reg;
>    unsigned short retaddr_column;
>    char saved[PRE_GCC3_DWARF_FRAME_REGISTERS+1];
> } frame_state;
> > structure, where PRE_GCC3_DWARF_FRAME_REGISTERS defaults to
> __LIBGCC_DWARF_FRAME_REGISTERS__, which is defined to
> DWARF_FRAME_REGISTERS, which defaults to FIRST_PSEUDO_REGISTER.
> So, changing FIRST_PSEUDO_REGISTER is an ABI change unless you 
arrange for

> PRE_GCC3_DWARF_FRAME_REGISTERS to be defined to the old value.
> >  Jakub
>
So where's the red flag that warns about this?

I also note that Richard Sandiford made a similar type of change for 
AArch64
in r10-4195 (183bfdafc6f1f98711c5400498a7268cc1441096) and nothing 
was said

about that at the time.

It seems incredibly fragile to me to have some ABI based off the 
number of

machine registers.


It is.  The new unwinder fortunately doesn't suffer from this (at least I
think it doesn't), but in older gccs the unwinder could be split 
across different
objects, having e.g. parts of the unwinder in one shared library and 
another

part in another one, each built by different GCC version.

Guess targets which weren't supported in GCC 2.x are ok, while
__frame_state_for is in libgcc, nothing calls it, so while such changes
change the ABI, nothing likely cares.
But for older targets it is a problem.

And it is hard to catch this in the testsuite, one would either need to
hardcode the count for each target in the test, or test with mixing 
GCC 2.x

compiled code with current trunk.

Before the introduction of libgcc_eh.a etc., parts of the unwinder was 
e.g.

exported from glibc.
See e.g. 
https://gcc.gnu.org/legacy-ml/gcc-patches/2001-07/threads.html#00472 


for some details.

 Jakub



So:
1) GCC-2.* didn't support the EABI, which is all we support these days.
2) the Arm port updated FIRST_PSEUDO_REGISTER in 2019 in r10-4441 
(16155ccf588a403c033ccd7743329671bcfb27d5) and I didn't see any fallout 
from that.

In fact it's been changed in

 16155ccf588a
 cf16f980e527
 0be8bd1a1c89
 f1adb0a9f4d7
 9b66ebb1460d
 5a9335ef017c

All since 2003 (ie since gcc-3.0 was released).

3) The Arm port uses the unwinding mechanism defined by the ABI, not the 
dwarf2 based tables.


So I'm inclined to think this probably isn't going to be a problem in 
reality.


R.

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Jakub Jelinek via Gcc-patches]

On Fri, Jan 13, 2023 at 10:39:59PM +, Richard Earnshaw wrote:
> > > It is.  The new unwinder fortunately doesn't suffer from this (at least I
> > > think it doesn't), but in older gccs the unwinder could be split
> > > across different
> > > objects, having e.g. parts of the unwinder in one shared library and
> > > another
> > > part in another one, each built by different GCC version.
> > > 
> > > Guess targets which weren't supported in GCC 2.x are ok, while
> > > __frame_state_for is in libgcc, nothing calls it, so while such changes
> > > change the ABI, nothing likely cares.
> > > But for older targets it is a problem.
> > > 
> > > And it is hard to catch this in the testsuite, one would either need to
> > > hardcode the count for each target in the test, or test with mixing
> > > GCC 2.x
> > > compiled code with current trunk.
> > > 
> > > Before the introduction of libgcc_eh.a etc., parts of the unwinder
> > > was e.g.
> > > exported from glibc.
> > > See e.g.
> > > https://gcc.gnu.org/legacy-ml/gcc-patches/2001-07/threads.html#00472
> > > 
> > > for some details.
> > 
> > So:
> > 1) GCC-2.* didn't support the EABI, which is all we support these days.
> > 2) the Arm port updated FIRST_PSEUDO_REGISTER in 2019 in r10-4441
> > (16155ccf588a403c033ccd7743329671bcfb27d5) and I didn't see any fallout
> > from that.
> In fact it's been changed in
> 
>  16155ccf588a
>  cf16f980e527
>  0be8bd1a1c89
>  f1adb0a9f4d7
>  9b66ebb1460d
>  5a9335ef017c
> 
> All since 2003 (ie since gcc-3.0 was released).

You're right, t-bpabi uses unwind-arm.c rather than unwind-dw2.c.
Sorry for the false alarm.

Jakub

Re: [GCC][PATCH 13/15, v5] arm: Add support for dwarf debug directives and pseudo hard-register for PAC feature.

[Richard Earnshaw via Gcc-patches]

On 13/01/2023 17:44, Srinath Parvathaneni via Gcc-patches wrote:

Hello,

This patch teaches the DWARF support in gcc about RA_AUTH_CODE pseudo 
hard-register and also
updates the ".save", ".cfi_register", ".cfi_offset", ".cfi_restore" directives 
accordingly.
This patch also adds support to emit ".pacspval" directive when "pac ip, lr, 
sp" instruction
in generated in the assembly.

RA_AUTH_CODE register number is 107 and it's dwarf register number is 143.

Applying this patch on top of PACBTI series posted here
https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599658.html and when 
compiling the following
test.c with "-march=armv8.1-m.main+mve+pacbti -mbranch-protection=pac-ret 
-mthumb -mfloat-abi=hard
fasynchronous-unwind-tables -g -O0 -S" command line options, the assembly 
output after this patch
looks like below:

$cat test.c

void fun1(int a);
void fun(int a,...)
{
   fun1(a);
}

int main()
{
   fun (10);
   return 0;
}

$ arm-none-eabi-gcc -march=armv8.1-m.main+mve+pacbti 
-mbranch-protection=pac-ret -mthumb -mfloat-abi=hard
-fasynchronous-unwind-tables -g -O0 -S test.s

Assembly output:
...
fun:
...
 .pacspval
 pac ip, lr, sp
 .cfi_register 143, 12
 push{r3, r7, ip, lr}
 .save {r3, r7, ra_auth_code, lr}
...
 .cfi_offset 143, -24
...
 .cfi_restore 143
...
 aut ip, lr, sp
 bx  lr
...
main:
...
 .pacspval
 pac ip, lr, sp
 .cfi_register 143, 12
 push{r3, r7, ip, lr}
 .save {r3, r7, ra_auth_code, lr}
...
 .cfi_offset 143, -8
...
 .cfi_restore 143
...
 aut ip, lr, sp
 bx  lr
...

Regression tested on arm-none-eabi target and found no regressions.

Ok for master?

Regards,
Srinath.

2023-01-11  Srinath Parvathaneni  

 * config/arm/aout.h (ra_auth_code): Add entry in enum.
 (emit_multi_reg_push): Add RA_AUTH_CODE register to
 dwarf frame expression.
 (arm_emit_multi_reg_pop): Restore RA_AUTH_CODE register.
 (arm_expand_prologue): Update frame related information and reg notes
 for pac/pacbit insn.
 (arm_regno_class): Check for pac pseudo reigster.
 (arm_dbx_register_number): Assign ra_auth_code register number in 
dwarf.
 (arm_init_machine_status): Set pacspval_needed to zero.
 (arm_debugger_regno): Check for PAC register.
 (arm_unwind_emit_sequence): Print .save directive with ra_auth_code
 register.
 (arm_unwind_emit_set): Add entry for IP_REGNUM in switch case.
 (arm_unwind_emit): Update REG_CFA_REGISTER case._
 * config/arm/arm.h (FIRST_PSEUDO_REGISTER): Modify.
 (DWARF_PAC_REGNUM): Define.
 (IS_PAC_REGNUM): Likewise.
 (enum reg_class): Add PAC_REG entry.
 (machine_function): Add pacbti_needed state to structure.
 * config/arm/arm.md (RA_AUTH_CODE): Define.

gcc/testsuite/ChangeLog:

2023-01-11  Srinath Parvathaneni  

 * g++.target/arm/pac-1.C: New test.
 * gcc.target/arm/pac-15.c: Likewise.


Your attachments are still not being correctly detected.  Perhaps this 
is because of the filename you've chosen, which has no recognizable 
extension.  If you name your files .patch (or .diff, or even 
.txt) then the system should automatically pick the right mime type 
for encoding.


+ /* NOTE: Dwarf code emitter handle reg-reg copies correctly and in the
+following example reg-reg copy of SP to IP register is handled
+through .cfi_def_cfa_register directive and the .cfi_offset
+directive for IP register is skipped by dwarf code emitter.
+Example:
+   mov ip, sp
+   .cfi_def_cfa_register 12
+   push{fp, ip, lr, pc}
+   .cfi_offset 11, -16
+   .cfi_offset 13, -12
+   .cfi_offset 14, -8
+
+Where as Arm-specific .save directive reg-reg copy handling is
+buggy.  After the reg-reg copy, the copied registers need to be

It's not buggy (if it were you'd need to fix it :).  It just works in a 
different way to the dwarf tracker and doesn't need to handle reg->reg 
copies.  So please rephrase this.


+populated in .save directive register list but with the current
+implementation of .save directive original registers are getting
+populated in the register list.  So to avoid this issue for IP
+register when PACBTI is enabled we manually updated the .save
+directive register list to use "ra_auth_code" (pseduo register 143)
+instead of IP register as shown in following example.
+Example:
+   pacbti  ip, lr, sp
+   .cfi_register 143, 12
+   push{r3, r7, ip, lr}
+   .save {r3, r7, ra_auth_code, lr}
+ */

R.