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: <37CD05AE.3280ABB4@1c.ru>
Date: Wed, 01 Sep 1999 14:53:34 +0400
From: Vadim Egorov <egorovv AT 1c DOT ru>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: ru,en
MIME-Version: 1.0
To: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>
CC: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: longjmp problem
References: <199908311407 DOT JAA14908 AT mercury DOT xraylith DOT wisc DOT edu>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-MDaemon-Deliver-To: cygwin-developers AT sourceware DOT cygnus DOT com
X-Return-Path: EgorovV AT 1c DOT ru


Hello,

Mumit Khan wrote:
> 
> Vadim Egorov <egorovv AT 1c DOT ru> writes:
> >
> > After digging around this problem I think that it concerns win32 SEH
> > mechanics. Following code shows the mutations of SEH frame
> > list while signals caused by exceptions are processed.
> 
> I suspect the same, but you're much further along than I am. I believe
> we have to start mucking with SEH to get things to work correctly, and
> the best source of information I've found so far is Pietrek's '97 article
> MSJ "A Crash Course on the Depths of Win32 Structured Exception Handling"
> that describes the except_handler crap in somewhat gory detail.
> 
> > before longjmp is enough but in general case when other seh frames
> > can be involved the task is more complicated.
> > I think SEH unwinding should be performed in longjump based on
> > target esp value.
> 
> And it gets worse when you're dealing with C++ exceptions on x86-win32,
> which currently uses setjmp/longjmp.

There are some considerations concerning this problem.

First, is the way of stack unwinding. We can simply reinstall last 
registered SEH frame that is on stack dismissing frames that was 
registered later. The appropriate frame can be stored in jmp_buf as 
MS do but I don't think it's a good idea to increase jmp_buf size.

For better interoperability with alien code that may use SEH it is 
necessary to call each of these handlers for unwinding so that they
could perform cleanup.

It seems possible to do it in MS like way described by Petrek but
it will impose some performance overhead on longjmp and on C++
exception handling accordingly.

But the problem with signal state still remains - it doesn't get
unblocked. If longjmp will perform more or less SEH frame unwinding
the same SEH technique can be here - to install additional exception
handler while signal handler is being called which would restore
signal state if unwinding occurred - but it doesn't look like the best
solution.


Vadim.


-- 
*********************************************
Vadim Egorov, 1C      *       Вадим Егоров,1C
egorovv AT 1c DOT ru         *         egorovv AT 1c DOT ru
*********************************************