dwarf2 signal unwind problem

Thu Apr 25 21:40:00 GMT 2002

We had a long discussion of this for IA64, though it may not have been
posted here. You have to remember that the personality function in
exception.cc (around line 240) again subtracts one from the PC.
We concluded that on IA64, things are set up so that the exception range
lookup actually needs the incremented PC (e.g. the return address),
eventhough the unwinder doesn't. The unwinder works because a faulting
load/store instruction can't affect the unwind information. Thus it's OK to
lie to it a little. This is not beautiful, but there didn't seem to be an
easy way to improve it. And I believe this part of the IA64 exception
mechanism is now correct.
Hans
-----Original Message-----
From: David S. Miller
To: java@gcc.gnu.org
Cc: aph@redhat.com; tromey@redhat.com
Sent: 4/25/02 8:15 PM
Subject: dwarf2 signal unwind problem
I think all Linux dwarf2 signal unwind implementations in libjava get
things subtly wrong. I noticed this while tracking down libjava
testsuite failures on sparc-linux.
Here is the comment that appears above every MAKE_THROW_FRAME
implementation currently in include/dwarf2-signal.h:
 /* ${CPU} either leaves PC pointing at a faulting instruction or the
\
 following instruction, depending on the signal. SEGV always does
\
 the former, so we adjust the saved PC to point to the following
\
 instruction; this is what the handler in libgcc expects. */
\
I don't see how this can be correct. Let me give an example
to show everyone why I think this way.
Consider an exception region consisting of one load instruction,
output by GCC as follows:
EXCEPTION_BEGIN_LABEL:
	LOAD 	NULL_POINTER, REG
EXCEPTION_END_LABEL:
This will elicit a SIGSEGV signal and cause MAKE_THROW_FRAME to
execute.
If we advance the program counter reported by the signal handler,
it will not match up in any of the exception region tables when
looked up at runtime.
Therefore I think every implementation of MAKE_THROW_FRAME in
this file is in error. They should not skip the PC over the
exception causing instruction.
...