RE: RFC: stack trace generation

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

Note that there is some interaction here with the heap debugging patch
(which is still not in the tree).  In debug mode, the garbage collector
likes to put a stack trace in every object, which makes stack traces much more
performance critical.  Frame-pointer-based unwinding seems OK.  David
Mosberger's libunwind would probably also be OK, though slower, since it does a fair
amount of caching.  I haven't looked enough at dwarf2-backtrace.cc to see
whether it could be used directly.

Currently the GC usually does its own unwinding on X86.
Since heap debugging currently requires a different build anyway, it would be
OK to just enable frame pointers (on X86) for those builds.

Hans

> -----Original Message-----
> From: java-owner@gcc.gnu.org 
> [mailto:java-owner@gcc.gnu.org]On Behalf Of
> Bryce McKinlay
> Sent: Tuesday, July 20, 2004 10:11 AM
> To: Andrew Haley
> Cc: David Daney; java@gcc.gnu.org
> Subject: Re: RFC: stack trace generation
> 
> 
> Andrew Haley wrote:
> 
> > > Yes.  The dwarf2-backtrace.cc is probably mis-named as it uses the
> > > functions that I believe you are referring to.
> > > 
> > > Being a very lazy person, I am only expending GCJ effort on the
> > > platforms that I am currently paid to support 
> (mipsel-linux*).  But
> > > I have to wonder if it would not be a win to use
> > > dwarf2-backtrace.cc with the i386-linux-gnu target and enable
> > > -fomit-frame-pointer.
> >
> >It might.  I think that's what Bryce intended to do.
> >
> Yeah, we are definitely going to do this. The only reason it 
> wasn't done 
> already time ago is due to the issues (PLT etc) that have 
> been discussed 
> already.
> 
> Regards
> 
> Bryce
>