> On 01/29/2012 07:57 AM, Tom de Vries wrote:
> > Richard,
> >
> > [now cc-ing gcc-patches]
> >
> > this patch fixes PR50283 in a target-independent way.
> >
> > it asserts on frame-related insns in the delay slot of insns that can
> > throw, and prevents the assert by testing for the same condition in
> > eligible_for_{delay,annul_true,annul_false}.
> >
> > build and reg-tested on mips64el.
> >
> > I don't know of any tests currently failing on this, so I think it's not
> > appropriate for stage4. OK for stage1 ?
>
> If we can't tell one unwinder (eh) what to do with this, how do we
> expect to be able to tell another unwinder (gdb)? Thus I'm not sure
> how "throwing" has anything to do with it.
If you need a reliable backtrace from any point then I guess you shouldn't
allow frame related insns in delay slots at all.
However this is a issue of debug experiance rather than code correctness. My
guess is most architectures don't allow you to singlestep into delay slots, so
any use of delay slots may cause lossage[1], not just frame related ones.
Debugging optimized code is always a compromise.
It's worth noting that -fasync-unwind-tables does not guarantee
backtrace/unwind from arbitrary points. Only from those instructions that may
result in a synchronous trap (which matches the semantics of this patch).
I'd guess that putting frame related insns in delay slots of libcalls is
probably a worthwhile optimization.
Paul
[1] If the insns come from different source lines.
