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

[Bryce McKinlay <mckinlay@redhat.com>]

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