GCJ Thread Dump

Thu Feb 10 19:23:00 GMT 2005

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.
>>