Re: Natively compiled SWT segfaults under Windows

[Olivier Parisy <ml dot olivier dot parisy at free dot fr>]

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.