RE: GCJ Thread Dump

["Boehm, Hans" <hans dot boehm at hp dot com>]

FWIW, the IA64 ABI requires accurate unwind information everywhere.
I had (wishfully?) thought that x86-64 had a similar requirement, but
I can't find it.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of David Daney
> Sent: Wednesday, February 09, 2005 3:53 PM
> To: Bryce McKinlay
> Cc: Andrew Haley; Mark Anderson; java@gcc.gnu.org
> Subject: Re: GCJ Thread Dump
> 
> 
> 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.
> 
> For some architectures (i.e. MIPS) it is possible to 
> backtrace in most 
> circumstances with neither DWARF data or frame pointers.  However I 
> think that things like ld.so's lazy resolution of dynamic library 
> symbols may cause even this technique to fail.
> 
> David Daney.
> 
>