This is the mail archive of the java@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: Natively compiled SWT segfaults under Windows


Ranjit Mathew wrote:

 Perhaps you mean MSVC when you say "a standard Win32 toolchain" (or
 the version that comes with the Platform SDK).

Yes, I used Visual C++ Express Edition and the Platform SDK, as they were free
to download. It seemed simpler to start with the toolchain targeted by SWT
makefiles.


 In any case, this compiler should have some option of retaining the
 frame pointer (using the EBP register) in the emitted code.

Actually, yes. I found this in the documentation of cl.exe (the Microsoft compiler front-end):
"If your code requires EBP-based addressing, you can specify the /Oy– option"
(http://msdn2.microsoft.com/en-us/library/2kxx5t2c.aspx)


I then disassembled versions of the SWT DLL to see the impact of this flag.

Without /Oy-:
_Java_org_eclipse_swt_internal_win32_OS_AbortDoc@12:
ff 74 24 0c push dword [esp+0xc]
ff 15 08 72 03 10 call [0x10037208]
c2 0c 00 ret 0xc

With /Oy-:
_Java_org_eclipse_swt_internal_win32_OS_AbortDoc@12:
55 push ebp
8b ec mov ebp,esp
ff 75 10 push dword [ebp+0x10]
ff 15 08 82 03 10 call [0x10038208]
5d pop ebp
c2 0c 00 ret 0xc

Some methods begin with 55 8b ec without this flag, but all do when using it
(excepted _JNI_OnLoad@8, interestingly).

 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 "different" circumstances.)

Considering the disassembled code above, this hypothesis looks rather robust.

 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.

Sadly, you're probably right: using the SWT DLL including proper frame pointer retaining led to exactly the same crash.

So there's either a problem with my GCJ build or with the backtrace
code, I suppose. Back to step one )-:

Best regards,
Olivier Parisy.


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