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

[Ranjit Mathew]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bryce McKinlay wrote:
> Ranjit Mathew wrote:
>>> 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.
>>>     
>> That worked pretty nicely, thank you. It reduces unnecessary
>> duplication of code too. The attached patch implements it and
>> was tested using a crossed-native compiler for i686-pc-mingw32.
>> I still get usable stack traces for compiled and interpreted
>> code.
>>
>> OK?
> 
> It occurs to me that you could now actually #define fallback_backtrace 
> as _Unwind_Backtrace, and get rid of some #ifdefs in stacktrace.cc. Do 
> you think that is worth doing? Otherwise, this is OK for trunk.

I've applied the attached patch to trunk. It defines _Unwind_Backtrace()
as fallback_backtrace() if SJLJ EH is in use. It was tested on
i686-pc-mingw32.

Even after this patch everything is not OK with the interpreter
and unwinding. While I get proper stack traces for programmes
that throw uncaught exceptions, I get a crashed interpreter for
programmes where the exception is caught. Some of the frames just
before _Jv_InterpMethod::run() have wild return addresses (even within
GDB) and I do not immediately understand why. I'll investigate this
further.
- -------------------------------- 8< --------------------------------
#13 0x0043bcd0 in _Jv_InterpMethod::run (retp=0x22fd80, args=0x22fda0,
    meth=0x2cd6f60) at /extra/src/gcc/gcc/libjava/interpret.cc:1221
#14 0xf8836606 in ?? ()
#15 0x0022fd80 in ?? ()
#16 0x0022fda0 in ?? ()
#17 0x02cd6f60 in ?? ()
#18 0x02cd6f60 in ?? ()
#19 0x02a1f098 in ?? ()
#20 0x02a139d0 in ?? ()
#21 0x0022fd98 in ?? ()
#22 0x00567e02 in _ZN4java4lang7reflect8Modifier8isPublicEJbi (mod=44138424)
    at /extra/src/gcc/gcc/libjava/java/lang/reflect/Modifier.java:257
#23 0x005e2be8 in gnu::java::lang::MainThread::call_main (this=0x2cc0fa0)
    at /extra/src/gcc/gcc/libjava/gnu/java/lang/natMainThread.cc:50
#24 0x0042fdff in _ZN3gnu4java4lang10MainThread3runEJvv (this=0x2cc0fa0)
    at /extra/src/gcc/gcc/libjava/gnu/java/lang/MainThread.java:108
#25 0x004550f4 in _Jv_ThreadRun (thread=0x2cc0fa0)
    at /extra/src/gcc/gcc/libjava/java/lang/natThread.cc:302
#26 0x00405136 in _Jv_RunMain (vm_args=0x22ff48, klass=0x0,
    name=0x3f2488 "Ex12", argc=1, argv=0x3f2504, is_jar=false)
    at /extra/src/gcc/gcc/libjava/prims.cc:1542
#27 0x004015e8 in main (argc=12, argv=0x7801392e)
    at /extra/src/gcc/gcc/libjava/gij.cc:333
- -------------------------------- 8< --------------------------------

Thanks,
Ranjit.

- --
Ranjit Mathew       Email: rmathew AT gmail DOT com

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




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEt9O4Yb1hx2wRS48RAgyMAJ92tLmo2x3Q3t6jDGrLAEZriwGD5wCfTik8
4tPj7wleovKU8ZLejmbWOpU=
=BJrv
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: p4.txt
URL: <http://gcc.gnu.org/pipermail/java-patches/attachments/20060714/b4b9c71d/attachment.txt>