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: Per Bothner <per at bothner dot com>
- Date: 07 Feb 2001 22:00:11 -0800
- Cc: gcc-patches at gcc dot gnu dot org, java at gcc dot gnu dot org
- References: <email@example.com><3A8225CB.7A9A5D9C@albatross.co.nz>
Bryce McKinlay <firstname.lastname@example.org> writes:
> I have no objection, although I would actually really like to see it
> demangle in the correct style for each frame, like gdb does. This
> can be done simply based on the extension of the source file
> reported for each frame, assuming that line number information is
> available (if not, I guess we'd just have to default to one or the
This can only be done by call a libary function on each output line,
as opposed to running throw c++filt. However, note that it gets a
little tricky with CNI native methods: They should be written in Java
style, but then how do we distinguish Java and C++ methods - we cannot
look at the file extension. Perhaps we really needs some distinction
is the mangled name to signfify a Java method.
> - drop the PC address display, because it takes up precious space
> and isn't really interesting for 99% of debugging tasks, and you can
> get it easily with gdb if you need it (the output will be much more
> readable if we can fit it on one line per frame in most cases). We
> could perhaps enable extra stuff for --enable-libgcj-debug builds
I have mixed feeling about this. The pc is useful when we don't have
line numbers available, and using gdb isn't always an option,
at least not online.
> I don't know if glibc has a demangler, but if it does then using it
> would open up version skew problems, at least until we're sure that
> everyone had a glibc new enough to support v3 java symbols.
That's what the configuration magic would have to check.