Mark Wielaard writes:
>
> I wrote the code assuming that we want our stacktraces to look just like
> conventional VM stacktraces and I believe this patch does that very
> nicely. But maybe I have to think outside the box to see what you are
> proposing here. (My box does not really include C or C++, as you have
> seen, my main programming experience is with logic/functional languages
> and some java.)
That's to assume that the "conventional" VM stack trace is, in some
way, ideal. However, I don't accept that it is ideal in our
environment where we link to CNI and JNI code and sometimes interact
with other languages and system interfaces.
My approach to libgcj has been that we should try to do better than
conventional VMs when we can. I believe that an informative stack
trace is one such opportunity.
I believe that for most GCJ users, it is better that the stack trace
resemble the traditional VM stack trace as closely as possible. The
problem with having too much additional information in there, such as
the PC for each frame, ambiguates the reason for the stack trace:
_quickly_ figuring out where and possibly why an exception occured.