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: <37CD5B09.2CFBAE44@col.bsf.alcatel.fr>
Date: Wed, 01 Sep 1999 18:57:45 +0200
From: Pascal Vittone <Pascal DOT Vittone AT col DOT bsf DOT alcatel DOT fr>
X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u)
MIME-Version: 1.0
To: Vadim Egorov <egorovv AT 1c DOT ru>
CC: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
Subject: Re: longjmp problem
References: <199908311407 DOT JAA14908 AT mercury DOT xraylith DOT wisc DOT edu> <37CD05AE DOT 3280ABB4 AT 1c DOT ru>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hello,

Vadim Egorov wrote:
> 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.

Isn't jmp_buf currently too big? Its size is 208 bytes and only 44 seems to be
used by setjmp. I don't understand why the structure is so big (Maybe _JBTYPE
macro should be defined as char?).

> 
> 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.

We could use the same (too?) simple solution as SUN. setjmp and longjmp become
_setjmp and _longjmp, sigsetjmp and siglongjmp call _setjmp and _longjmp, and
setjmp and longjmp call sigsetjmp and siglongjmp using the current signal mask
as parameter for sigsetjmp. Obviously, jmp_buf and sigjmp_buf must be the same
data type.

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

Thanks for your time.

Pascal Vittone

-- 
                                                    ________________
____________________________________________________\              /_______
Pascal Vittone		ESD/EBU/LSD/R&D
mailto:Pascal DOT Vittone AT col DOT bsf DOT alcatel DOT fr	Alcatel Business Systems
Tel: +33 (0)1 55 66 56 77			   54, av. Jean Jaures
Fax: +33 (0)1 55 66 54 24			     F-92700 Colombes
_________________________________________________________\    /____________
                                                          \  /
                                                           \/