> On 01/30/2012 11:07 AM, Paul Brook wrote:
> > 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).
>
> ... and we're not
On 01/30/2012 11:07 AM, Paul Brook wrote:
> 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).
... and we're not talking ab
On 01/30/2012 11:07 AM, Paul Brook wrote:
> 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.
Certainly Sp
> 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 condi
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
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
