On Tue, Feb 04, 2014 at 11:33:57AM +0000, Richard Sandiford wrote:
> > So, how does the lmg insn look like in RTL dump on some problematic
> > testcase?
> > insn_stack_adjust_offset_pre_post already uses REG_FRAME_RELATED_EXPR,
> > which is also a kind of CFI note (the oldest one), so likely the issue
> > is just that it hasn't been adjusted to handle other newer REG_CFA_* notes
> > that tell how the stack pointer is adjusted.
>
> It's just a (mem ...) access:
>
> (parallel
> [...
> (set (reg %r14) (mem:[SD]I (plus (reg ...) (const_int X1))))
> (set (reg %r15) (mem:[SD]I (plus (reg ...) (const_int X2))))])
I meant what reg notes it has (and why it doesn't use
REG_FRAME_RELATED_EXPR).
> >> The simplest fix seems to be to disable this check for the exit block.
> >> We never use its stack_adjust anyway, and dwarf2cfi already checks
> >> (using CFA information) that the offsets in a shrink-wrapped function
> >> are consistent.
> >>
> >> Tested on s390-linux-gnu and s390x-linux-gnu. OK to install?
> >
> > I don't like this, my strong preference is to handle REG_CFA_* notes.
>
> But then we wouldn't be able to use var-tracking when __builtin_eh_return
> is used, since in that case replacing the (set (reg ...) (mem ...))
> with a (plus ...) would be incorrect -- the value we're loading from the
> stack will have had a variable adjustment applied. And I know from painful
> experience that being able to debug the unwind code is very useful. :-)
Aren't functions using EH_RETURN typically using frame pointer?
And, var-tracking disabling doesn't really mean no debug info, just worse
debug info. IMHO the sanity check in var-tracking is worth much more than
var-tracking in unwind-dw2.o in the case where you wouldn't use frame
pointer. Why doesn't dwarf2cfi ICE on it then when the CFA changes can't be
described properly?
Jakub
