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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [MinGW] RFA: Make Stack Traces Work for Interpreted Code on Windows


Ranjit Mathew wrote:
Note that even then there are some situations (invocation API) where
neither _Jv_RunMain or _Jv_ThreadStart will be on the stack.

...would you happen to know what *will* be there on the call stack in this case?

I don't think there is anything guaranteed in the invocation API case. For JNI you could look for the various JNI Call* functions, but even then it is tricky to figure out whether the frame you are looking at is the outermost JNI call.


This part of the patch is a bit awkward - duplicating the
interpreter-specific code is fragile and will make maintenance more
difficult. Couldn't we instead have fallback_backtrace call the real
UnwindTraceFn? I believe _Unwind_context is an opaque type, so it should
be possible to have fallback_backtrace pass its own data there.

I sort of agree. However, if you look at the code there, it calls _Unwind_GetRegionStart() and _Unwind_GetIPInfo() - I'll have to #ifdef these out and somehow shoehorn the SJLJ EH equivalents in there since the default implementations of these functions provided by GCC for SJLJ EH are of no use to us.

I think you could just overload them with #defines in backtrace.h? Failing that, I think that adding a couple of #ifdef's in UnwindTraceFn is not as bad as the code duplication.


Hmm. There shouldn't be any problems here (on Linux) - do you have a
test case?

Yes. See: - ---------------------------- 8< ---------------------------- 1 public class Ex { 2 void snafu( ) throws Exception { 3 throw new Exception( "I do not like you!"); 4 } 5 void bar( ) throws Exception { 6 snafu( ); 7 } 8 void foo( ) throws Exception { 9 bar( ); 10 } 11 public static void main( String[] args) throws Exception { 12 new Ex( ).foo( ); 13 } 14 } - ---------------------------- 8< ----------------------------

Hmm, ok, I see this too. I've filed a bug:


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28352

Bryce


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