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.
