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 +0000, 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.
