This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [patch] java run-time stack trace


Bryce McKinlay <bryce@albatross.co.nz> 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
> other).

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
> though.

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.

-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]