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

[Jakub Jelinek <jakub@redhat.com>]

On Fri, Jan 13, 2023 at 09:58:26PM +0000, 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