Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199909072107.QAA18307@mercury.xraylith.wisc.edu>
To: Vadim Egorov <egorovv AT 1c DOT ru>
cc: "cygwin-developers AT sourceware DOT cygnus DOT com" <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: setjmp/longjmp patch update 
In-Reply-To: Your message of "Tue, 07 Sep 1999 11:56:00 +0400."
             <37D4C510 DOT 7C473183 AT 1c DOT ru> 
Date: Tue, 07 Sep 1999 16:07:42 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

Vadim Egorov <egorovv AT 1c DOT 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