Re: GCJ Thread Dump

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > Bryce McKinlay wrote:
 > > David Daney wrote:
 > > 
 > >>
 > >> The problem I see is that for targets that have no frame pointer.  
 > >> These have to use the DWARF .eh_frame information for generating 
 > >> stacktraces.    The stop-the-world uses asynchronous signals and these 
 > >> are not compatible with DWARF exception handling.
 > > 
 > > On most platforms, we can unwind through signal handlers thanks to 
 > > MD_FALLBACK_FRAME_STATE_FOR - this is how NullPointerException is 
 > > implemented.
 > 
 > Indeed I know all about MD_FALLBACK_FRAME_STATE_FOR.  The problem is 
 > that gcc only generates good unwinding data for instructions that can 
 > fault (ie synchronous signals).  In general it does not work for 
 > asynchronous signals (which are used to stop-the-world) as that would 
 > require much larger tables.

Exactly right.  In particular, we do not generate unwinder information
for prologues and epilogues.  If a thread is pre-empted during one of
these, we don't have any way to find a valid frame pointer.

Andrew.