Re: RFC: stack trace generation

[Andrew Haley <aph at redhat dot com>]

Casey Marshall writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> Casey Marshall writes:
 > >> Something I've been working on recently is finding a way to get a
 > >> decent Java stack trace, complete with file and line number
 > >> information, without using external processes (the problems with
 > >> GCJ's Process implementation notwithstanding, the current method is
 > >> too slow, and doesn't work on my target platform when a lot of the
 > >> code is in shared libraries).
 > 
 > Andrew> Bryce has been working on a patch for this for some time now.
 > Andrew> It's different from what you have because it uses gcj's
 > Andrew> reflection data.  I'm pretty sure that this is the right way
 > Andrew> to go.  However, there have been a few problems with PLT
 > Andrew> entries.
 > 
 > Hmm, "Bryce is working on it" seems like it's the answer I've been
 > getting for a while now ;)

Ah, okay.  I just wanted to me sure that you were fully aware of
Bryce's work.

 > What I was more interested in was changing the file/line lookup
 > code in NameFinder, and whether or not a shared library DWARF-2
 > parser would be a part of that. I've improved what I posted earlier
 > a great deal, so it is not unreasonably slow, and produces fairly
 > accurate debug traces.

My first reaction to this is that I'm a bit reluctant to put DWARF2
parsing into libgcj, but if that's agreed by common consent to be a
good solution I won't argue.  

However, if we can fix this PLT problem with a change to gcc I believe
that the reflection metadata was is the right way to go.  To a large
extend the DWARF debug info and the reflection metadata are redundant,
but we support metadata on every target and DWARF info on only some of
them.

Andrew.