Re: Problems with _Unwind_Backtrace() vs signal handlers

[Geoff Keating <geoffk at geoffk dot org>]

On 01/08/2004, at 5:45 AM, Geert Bosch wrote:

> On Aug 1, 2004, at 01:58, Geoffrey Keating wrote:
> > Sounds like a bug in MD_FALLBACK_FRAME_STATE_FOR on your platform.
> > I'd suggest looking at the powerpc-darwin implementation for
> > an indication of how to get this right.
>
> For signal handlers (esp. as a result of a trapping insn) you do not
> generally want the instruction after the one that faulted, as that
> would be ill-defined for an indirect jump with an invalid address
> for example.

On powerpc, at least, when you trap as the result of jumping to an 
invalid address, the instruction that trapped is at the invalid 
address, so it usually doesn't matter either way (there will be no EH 
information for the invalid address, since there's no valid instruction 
there, and there's no easy way to get the address of the previous 
instruction in execution order).

> However, I believe that the unwinder always subtracts one (byte/word)
> from the return address in order to get the right context for the
> exception in the normal call case: a new exception handling region
> might start right after  the call instruction. So to compensate for
> that you'd have to add one (byte/word) to the address of the faulting
> instruction in MD_FALLBACK_FRAME_STATE_FOR.

That would work, too.

Attachment: smime.p7s
Description: S/MIME cryptographic signature