Fix PR24908: ICE in dwarf2out for cpu2000 with -funroll-loops
Alan Modra
amodra@bigpond.net.au
Sat Nov 19 05:50:00 GMT 2005
On Sat, Nov 19, 2005 at 09:57:31AM +1030, Alan Modra wrote:
> On Fri, Nov 18, 2005 at 02:08:41PM -0800, Geoff Keating wrote:
> > I'm pretty sure we can generate them even in the prolog; you see code
> > like
> >
> > mflr r12 // save return address in r12
> > bl __GLOBAL_OFFSET_TABLE__@local
> > mflr r28 // save GOT address in r28 (not frame related)
> > mtlr r12 // restore return address from r12
> >
> > I don't know if this code tries to deal with that or not; maybe we
> > just don't mark the save/restore as frame related and hope that no
> > trapping operation gets scheduled between the 'mflr' and the 'mtlr'.
>
> Hmm, if we don't track the restore of lr in this case, then we will
> confuse the unwinder. Imagine unwinding through a point a little later
> in the function where we have used r12 as a scratch. Unless we tell the
> unwinder that the return address is no longer in r12, it will use an
> invalid address as the return.
dwarf2out is quite clever and tracks registers with regs_saved_in_regs.
For the testcase in pr24908, I see the following for the code sequence
Geoff shows above, except of course r26 is used instead of r12:
DW_CFA_register: r108 in r26
[snip]
DW_CFA_same_value: r108
The DW_CFA_same_value says lr is restored to its original value. I
think that regs_saved_in_regs along with the fact that we are only
interested in the prologue means that Geoff's concern about saves vs
restores are covered.
--
Alan Modra
IBM OzLabs - Linux Technology Centre
More information about the Gcc-patches
mailing list