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

["Ranjit Mathew" <rmathew@gmail.com>]

[Apologies if you see this message twice. Gmail's SMTP server is
acting weird.]

Bryce McKinlay wrote:
> Ranjit Mathew wrote:
>>
>> The fix was to change fallback_backtrace() in
>> "sysdep/i386/backtrace.h" to stop on _Jv_RunMain() instead since
>> this does occur in both interpreted and natively-executed call
>> stacks. (Since this function is overloaded, I needed to use an
>> interim variable with the appropriate cast to tell the compiler
>> which of these function variants to pick up.)
>>
>
> Only the main thread will have JvRunMain on the stack - you probably
> also need to look for the thread-start routine to handle other threads.

Good point. So I can stop unwinding when I see either
_Jv_RunMain() or _Jv_ThreadStart().

However...

> 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?


>> fallback_backtrace() also does not correctly handle unwinding
>> through interpreted code. The fix was as simple as copying the
>> relevant bits of code from _Jv_StackTrace::Unwind_TraceFn() and
>> adjusting it a little bit.
>>
>
> 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.

The bigger picture however is that I expect all this to be
unnecessary in 4.3 - we would hopefully switch to DW2 EH
for MinGW by then.


>> (I note that under the interpreter we do
>> not get line numbers for the innermost call frame, even on Linux.
>> I haven't investigated this issue yet.)
>>
> 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< ----------------------------

- ---------------------------- 8< ----------------------------
~/src/tmp > $MYGCJ --version
gcj (GCC) 4.2.0 20060701 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~/src/tmp > $MYGCJ --main=Ex -g Ex.java
~/src/tmp > ./a.out
Exception in thread "main" java.lang.Exception: I do not like you!
   at Ex.snafu(Ex.java:2)
   at Ex.bar(Ex.java:6)
   at Ex.foo(Ex.java:9)
   at Ex.main(Ex.java:12)
~/src/tmp > $MYGCJ -C Ex.java
~/src/tmp > mygij Ex
Exception in thread "main" java.lang.Exception: I do not like you!
   at Ex.snafu(Ex.java)
   at Ex.bar(Ex.java:6)
   at Ex.foo(Ex.java:9)
   at Ex.main(Ex.java:12)
~/src/tmp > mygij --version
java version "1.4.2"
gij (GNU libgcj) version 4.2.0 20060701 (experimental)

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
~/src/tmp >
- ---------------------------- 8< ----------------------------

Note that this is a slightly older build and does not have your
_UnwindGetIPInfo() changes, so the problem has very likely been
fixed in recent builds.

Thanks,
Ranjit.

-- 
Ranjit Mathew      Email: rmathew AT gmail DOT com

Bangalore, INDIA.    Web: http://rmathew.com/