RFC: stack trace generation
Tue Aug 3 17:09:00 GMT 2004
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.
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org]On Behalf Of
> Bryce McKinlay
> Sent: Tuesday, July 20, 2004 10:11 AM
> To: Andrew Haley
> Cc: David Daney; email@example.com
> 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
More information about the Java