dwarf2 signal unwind problem

dwarf2 signal unwind problem

[David S. Miller]

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.

This brings me to my second observation, which probably indicates
another similar error in all of the current dwarf2 signal unwind
implementations.

Sometimes, when an unwind out of a signal handler occurs, the
unwind code has to walk the stack from the beginning multiple
times to find out who to really unwind to.

Secondly, the unwind code has to adjust the context->ra value on
some platforms to make the return PC point to the right place.
See gcc/unwind-dw2.c:uw_update_context(), specifically this:

  /* Compute the return address now, since the return address column
     can change from frame to frame.  */
  context->ra = __builtin_extract_return_addr
    ((void *) (_Unwind_Ptr) _Unwind_GetGR (context, fs->retaddr_column));

In order for the signal unwind PC to be instruction accurate
(and as my single LOAD exception region above shows, it must
 be instruction accurate for it to work in all cases) things
must be setup such that MAKE_THROW_FRAME compensates for this
adjustment that the unwind code in GCC is going to make.

One might think that we could make the adjustment in
MD_FALLBACK_FRAME_STATE_FOR, but because the unwind tree could be
walked multiple times (and MD_FALLBACK_FRAME_STATE_FOR thus called
multiple times for the same signal frame) this solution would not
work.  It must be adjusted in MAKE_THROW_FRAME for correct operation
in all cases.

I know my initial Sparc implementation got both of these issues wrong,
and I am fixing that up now (expect a patch to java-patches shortly).

But I encourage the implementors of the other MAKE_THROW_FRAME
instances in dwarf2-unwind.h to take a good hard look at this
because I think they have at least one of these bugs too!

Re: dwarf2 signal unwind problem

[David S. Miller]

   From: "Boehm, Hans" <hans_boehm@hp.com>
   Date: Thu, 25 Apr 2002 21:31:11 -0700

   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.

Indeed, I had totally missed this.  There is a followup coming where I
correct this. :-)

Note that the other side of the issue still holds up (unwind's PC
adjustment), but I am less concerned that ports get that wrong.

RE: dwarf2 signal unwind problem

[Boehm, Hans]

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.

...