Re: [PATCH] DWARF-2 unwinder off-by-one problem with signal frames

[Richard Henderson <rth at redhat dot com>]

On Wed, Jun 30, 2004 at 03:43:28PM +0200, Ulrich Weigand wrote:
> The question is how to fix this.  Going back one byte makes perfect
> sense for a normal 'return address' pointing to *after* a call insn.
> However, for the special case of a signal handler 'return address',
> which may well point *to* the trapping insn, it is wrong.

At present the fix is to not do *anything* different in the unwinder.

It's the responsibility of the signal handler to distinguish between
the case of a signal that points to the beginning of the trapping
insn (SEGV), and one that points to the end (FPE).  See all the
frobbing that goes on in libjava to handle these cases.

I'll admit that it would be more ideal for the user if this were
all done automatically, but given the amount of variance in behaviour
of signals on different platforms, I don't know how to do this.

> GDB has the same problem, but there it is solved by explicitly
> distinguishing the two cases, see frame_unwind_address_in_block:

GDB doesn't have to look for EH regions and actions, and thus can
get away with ignoring how FPE differs from SEGV.

> OK?

Not ok.

If you want to fix this particular testcase in the testsuite,
then we just need to add some code to separate the stack frame
setup and the segv.  Perhaps storing to a global variable?


r~