On Fri, Jan 13, 2023 at 10:39:59PM +0000, 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
> > > <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
