From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19855 invoked by alias); 5 Aug 2005 15:57:49 -0000 Mailing-List: contact insight-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: insight-owner@sourceware.org Received: (qmail 19833 invoked by uid 22791); 5 Aug 2005 15:57:45 -0000 Received: from fra-del-04.spheriq.net (HELO fra-del-04.spheriq.net) (195.46.51.100) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 05 Aug 2005 15:57:45 +0000 Received: from fra-out-02.spheriq.net (fra-out-02.spheriq.net [195.46.51.130]) by fra-del-04.spheriq.net with ESMTP id j75FvgHG018863 for ; Fri, 5 Aug 2005 15:57:42 GMT Received: from fra-cus-01.spheriq.net (fra-cus-01.spheriq.net [195.46.51.37]) by fra-out-02.spheriq.net with ESMTP id j75FveM0001517 for ; Fri, 5 Aug 2005 15:57:42 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-01.spheriq.net with ESMTP id j75FvdRP016520 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 5 Aug 2005 15:57:40 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 77EFFDA42; Fri, 5 Aug 2005 15:57:39 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id 3A1DA475DA; Fri, 5 Aug 2005 15:59:49 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id C40B4759B3; Fri, 5 Aug 2005 15:59:48 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 359FA47523; Fri, 5 Aug 2005 15:59:48 +0000 (GMT) Received: from terrorhawk.bri.st.com (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id BSH03327 (AUTH "andrew stubbs"); Fri, 5 Aug 2005 16:57:37 +0100 (BST) Date: Fri, 05 Aug 2005 15:57:00 -0000 To: "Dave Korn" , insight@sources.redhat.com Subject: Re: MinGW setjmp SEGV References: From: Andrew STUBBS Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: User-Agent: Opera M2/8.01 (Win32, build 7642) X-O-General-Status: No X-O-Spam1-Status: Not Scanned X-O-Spam2-Status: Not Scanned X-O-URL-Status: Not Scanned X-O-Virus1-Status: No X-O-Virus2-Status: Not Scanned X-O-Virus3-Status: No X-O-Virus4-Status: No X-O-Virus5-Status: Not Scanned X-O-Image-Status: Not Scanned X-O-Attach-Status: Not Scanned X-SpheriQ-Ver: 2.2.3 X-SW-Source: 2005-q3/txt/msg00056.txt.bz2 > I don't understand the need for it yet, though; can you enlarge on the > problem or point me at a tcl.sourceforge bugzilla report? See: http://sources.redhat.com/ml/insight/2004-q1/msg00021.html The problem is that the assembly code is broken (reentrancy aside). It saves the value of %fs:0 (the pointer to the exception handler I think, but I'm not totally clear on this), but the restore code is broken and just writes random data. The next function in Insight to dereference this pointer is in setjmp so we see the crash there. > This patch would > affect cygwin as well as mingw, since it also defines HAVE_NO_SEH; > AFAIUI, > the macro means 'have no seh support in the compiler' rather than 'have > no > seh in the target OS', but cygwin (apparently) is happy enough using > 'doze > SEH, and I don't understand the comment about "Unlike Borland and > Microsoft > we don't .... pushing registration records onto the runtime stack." Yet > the EXCEPTION_REGISTRATION variable "registration" is on the stack and > appears to be linked into the 'doze SEH chain in pretty much the usual > fashion. I'm sure this is just my lack of comprehension. As I understand it, the assembler code is supposed to simulate the '__try {} __except {}' stuff in compilers which do not support that. I don't know what compilers do support it though. Cygwin's 'gcc -mno-cygwin' does not. I don't understand the comment either. Obviously the GCC compiled Insight/TCL does not use this stuff automatically, but the msvcrt.dll does use it - I can see it in the disassembly. I would imagine that any other MSVC compiled DLLs also use it. Perhaps it makes more sense along with the rest of the updated TCL, but as far as I can tell it is local to this one file and only used three times (once here). > OTOH this patch would seem to address my concerns about the reentrancy > problems of using static _ESP and _EBP variables. I don't know about that, I just cut a pasted the code from sourceforge. > Should or shouldn't the same changes be made to the exception handling > in > tclWinFCmd.c and tclWinChan.c as well? There is other similar code in sourceforge, but not all of it is relevant so I just took enough to fix the problem at hand. See http://cvs.sourceforge.net/viewcvs.py/tcl/tcl/win/tclWin32Dll.c?rev=1.46&view=auto I have submitted this to help, but you should be aware that I am not certain whether any ST copyright stuff may be used in Insight (particularly the TCL parts), although we do have an assignment for GDB. That's part of the reason why I have not submitted the full set of patches to make Insight go. The TCL stuff from sourceforge is obviously not a problem, at least not if you get it from there yourself. Andrew Stubbs