Re: Natively compiled SWT segfaults under Windows [Summary]

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

Ranjit Mathew wrote:

>  Olivier Parisy wrote:
>
> > Considering the disassembled code above, this hypothesis looks
> > rather robust.
>
>  No. Look at the opcodes for the instructions comprising the prologue
>  - it's "0x55 0x8B 0xEC" instead of the "0x55 0x89 0xE5" assumed by
>  the code. Both represent "PUSH ebp; MOV ebp, esp", but the encoding
>  used is different.

Yes, I read too fast; I didn't expect that kind of opcodes aliases.

>  If you want to continue with the existing kludge, you can modify
>  "libjava/sysdep/i386/backtrace.h" like so:
>  [...]
>
>  recompile libjava and see if it fixes your problem.

Actually, it did! Moreover, it worked with the original SWT DLL. It seems
like the functions prologues present in this code were sufficient for 
unwinding
purpose, after all. The problem was just with their encoding and subsequent
detection.

For the record (and future reference):
- Unwinding through stack frames is needed during SWT display 
initialization.
- Applying your patch was mandatory for this unwinding to work.
- Compiling with -fno-omit-frame-pointer was not needed.
- Rebuilding the SWT DLL with the  /Oy- flag was not mandatory.

>  A "proper" solution would be to use a prologue analyser like that
>  used in GDB:
>
>  http://sources.redhat.com/gdb/onlinedocs/gdbint_3.html#SEC8

Very interesting reading. Thanks for the link.

>  but that is too much work for too little a gain.

Perhaps this functionality will be available in a library in the future...

In the meantime, could you commit your patch to libjava? As I understand
it, this should have no side effects, and is needed for proper SWT 
operation.

Best regards,
Olivier Parisy.