Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com Message-Id: <199908311407.JAA14908@mercury.xraylith.wisc.edu> To: Vadim Egorov cc: cygwin-developers AT sourceware DOT cygnus DOT com Subject: Re: longjmp problem In-Reply-To: Your message of "Tue, 31 Aug 1999 14:55:29 +0400." <37CBB4A1 DOT 85DE3BEA AT 1c DOT ru> Date: Tue, 31 Aug 1999 09:07:12 -0500 From: Mumit Khan Vadim Egorov 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. > I would be grateful to here any comments about my conclusions > before I try to invent a fix for it. You seem to be ahead of everyone here, so please go forth and do invent! We really need someone who knows SEH inside out (from a compiler perspective, not win32 API perspective). I have get most of the code out of Pietrek's article, but I lack the expertise in x86 to do anything more with it. Regards, Mumit