This is the mail archive of the
mailing list for the Java project.
Re: Natively compiled SWT segfaults under Windows
-----BEGIN PGP SIGNED MESSAGE-----
Olivier Parisy wrote:
> Ranjit Mathew a écrit :
>> If you're using a recent GCJ/Win32, -fno-omit-frame-pointer is
>> already used while compiling Java to native code.
>> You should compile the native code (SWT DLL) also with frame
>> pointers enabled.
> Well, that's kind of what I feared. I've been able to compile a working
> SWT DLL,
> but I had to use a standard Win32 toolchain for this purpose as the provided
> makefiles are specifically tuned for this building environment.
Perhaps you mean MSVC when you say "a standard Win32 toolchain"
(or the version that comes with the Platform SDK). In any case,
this compiler should have some option of retaining the frame
pointer (using the EBP register) in the emitted code.
> On a broader scope, should all DLL used with gcj be rebuilt with the
> -fno-omit-frame-pointer flag? Isn't this a rather strong condition to
If you need to unwind through a function in a DLL and get the
stack trace, you need to compile the DLL with frame pointers
enabled. (Even then the current code is quite kludgy - it
assumes that the initial part of a function prologue is a
sequence of "PUSH ebp; MOV ebp, esp" instructions which
might not be true for other compilers or even GCC under
Note that even if GCJ/Win32 were using DWARF-2 exception
handling, it would still mean that the native DLL be compiled
using GCC or some other compiler that emits DWARF-2 unwind
data compatible with that used by GCC.
Finally, Olivier please note that I do not know if this
indeed is the problem troubling you. It could well be
that the current GCJ/Win32 backtrace code has a bug that
you are hitting.
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://rmathew.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v18.104.22.168 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----