This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: where do stack traces get filled in?
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'Jeff Sturm'" <jsturm at one-point dot com>, Andrew Haley <aph at cambridge dot redhat dot com>
- Cc: tromey at redhat dot com, Adam Megacz <gcj at lists dot megacz dot com>, java at gcc dot gnu dot org, "MOSBERGER, DAVID (HP-PaloAlto,unix3)" <davidm at hpl dot hp dot com>, "'rth at redhat dot com'" <rth at redhat dot com>
- Date: Thu, 13 Dec 2001 13:10:10 -0800
- Subject: RE: where do stack traces get filled in?
David Mosberger has started a project to unify all the unwind code for IA64,
and has discussed this with Richard Henderson. This started out relying on
a lower level IA64-specific unwinder interface. But the latest version of
the interface is intended to be machine-independent.
I'm not sure whether this will be done in a 3.1 timeframe. (I'm personally
also a little concerned about doing this to close before a release.) But
David (and Richard?) should definitely be involved in any discussions along
these lines.
Hans
> -----Original Message-----
> From: Jeff Sturm [mailto:jsturm@one-point.com]
> Sent: Thursday, December 13, 2001 8:03 AM
> To: Andrew Haley
> Cc: tromey@redhat.com; Adam Megacz; java@gcc.gnu.org
> Subject: Re: where do stack traces get filled in?
>
>
>
>
> On Thu, 13 Dec 2001, Andrew Haley wrote:
> > What I would like, in the general case, is to expose the logic in
> > gcc's exception unwinder so that it can be used by backtrace.
>
> I think that's a winning idea. It would let us easily do
> backtraces on
> machines where we can't walk the stack (alpha) or on systems
> that don't
> have glibc (Solaris).
>
> Of course it wouldn't work for sjlj-exceptions, but that's just more
> incentive to fix the remaining targets that still need it...
>
> Assuming someone has the time, I wonder if Mark would let us
> slip it in
> for 3.1 (which is rapidly approaching a feature-freeze). I'm assuming
> this would go somewhere like unwind.inc, since most of the required
> functions and data structures aren't public.
>
> Jeff
>