This is the mail archive of the
mailing list for the GCC project.
Re: [patch] java run-time stack trace
- To: Bryce McKinlay <bryce at albatross dot co dot nz>
- Subject: Re: [patch] java run-time stack trace
- From: Andrew Haley <aph at redhat dot com>
- Date: Thu, 8 Feb 2001 09:33:16 +0000 (GMT)
- Cc: Per Bothner <per at bothner dot com>, gcc-patches at gcc dot gnu dot org,java at gcc dot gnu dot org
- References: <firstname.lastname@example.org><3A8225CB.7A9A5D9C@albatross.co.nz>
Bryce McKinlay writes:
> Per Bothner wrote:
> > This patch accomplishes that. It does have the undesirable side-effect that
> > C or C++ functions are are written Java-style (i.e no * or ::):
> > at 0x40186645: _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/home/bothner/GNU/linux/lib/libgcj.so.1)
> > but I think that is reasonable enough for a Java stack printer.
> > Any objections to checking this in (now, before the branch)?
> - drop the PC address display, because it takes up precious space
> and isn't really interesting for 99% of debugging tasks
I've had *very* emphatic demands for the PC display in embedded
systems for post mortem dumps. It's not like you can always attach a
gdb to the process. Embedded systems are a very important part of
users of gcj.
It's clear that people have very different requirements for backtrace:
any change should be configurable, and IMO runtime configurable.
> - print line number information for frames from shared libs. In
> order for this to work we'd need to either open up multiple
> sessions of addr2line (one for each shared lib);
Yes, that would be an improvement.
> or just call into libbfd directly.
This is a GPL issue: if it had been possible legally to link with
libbfd we would have done that already instead of all this messing
about invoking an external program.