This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


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

Re: setjmp/longjmp patch update


Vadim Egorov <egorovv@1c.ru> writes:
> Hello,
> 
> Here is a path which fixes the problem with longjmp when it is called 
> from signal handler.
> setjmp is modified to store fs:0 (SEH handler) value at offset 44 of
> jmp_buf. longjmp in turn checks this value and invokes seh_unwind if 
> necessary. 
> It handles win32 exceptions raised as signals such as SIGFPE and 
> SIGSEGV and preserves SEH handler list in a consistent state.


Hi Vadim,

Excellent! This looks and feels like the right approach, but I need to 
convince myself of that. Pietrek's '97 MSJ article title "A Crash Course 
on the Depths of Win32 Structured Exception Handling" is the only place 
where I've seen some details, so I guess it's time for me to really 
understand what's going on here.

BTW, there is a good reason why MS compiler provide two versions of
setjmp/longjmp -- one that unwinds (slow) and one that does not (the
*ex version, fast). There is also the issue of windows32 native signals 
being handled by separate threads, and that gets in the way of setjmp
longjmp etc using the "wrong" stack. This is not an issue for Cygwin
as far as I can tell.

> This makes possible to use malicious SEH for good things.
> In this patch I modified signal handler invocation code to call
> signal handler guarded by a __try/__finally fashioned block.

Actually, SEH is a very good innovation in Windows32 and now implemented
in True64 [1] as well. Most Unix vendors simply refuse to deal with this 
issue unfortunately. Asynchronous exceptions can really help in the design 
of certain class of applications, and avoid the truly gross hacks used
when these are coded under most existing Unix implementations. There are
times when I do miss VMS.

[1] you know, the OS that started out life as OSF/1, then to Digital Unix, 
and now known as True64.  Worse than the what's the current symbol
formerly known as Prince ;-)

> It installs additional seh frame around the call which guarantees
> that signal state will be restored even if handler doesn't return 
> due to the longjmp call.

I'll try out the patch hopefully soon. Thanks for working on this issue.

Regards,
Mumit



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