> My objection was about local_unwind2, where you were using %esp to
> reference local variables. This cannot work, even if you don't modify
> %esp in the inline assembly.
Got it, chaining the exception frame using esp is only valid if gcc pushes
the registration struct onto the stack (not a safe assumption). I should have
checked the existing exception handling code closer before starting (doh).
<from prev mail>
>If you need to call functions with a specific %ebp, you can write a
>small wrapper function (using __ASM_GLOBAL_FUNC) that does just that;
Well, this _should_ be done, but actually it doesn't matter at the moment,
since the code to actually clean up during local unwind isn't written (and
I'm not going back to it for a while). So since no dtors etc can get called,
its not relevant whether or not we set %ebp for them. Consequently I've taken
the easy way out and replaced the asm with straight calls, except for the
call to the 'finally' block (which is non gcc code, so no problem). It may
end up being viable to set %ebp just before calling the cleanup code inside
unwind (where we can push'n'pop it) instead of before the unwind function
anyway.
You can ignore the patch I sent to wine-devel. The one I just posted on
wine-patches "msvcrt exceptions" should be OK, and superceeds it.
Cheers,
Jon
--
"Once you realise you're not _meant_ to fit in, it all makes sense..."
[EMAIL PROTECTED] , [EMAIL PROTECTED]
