From owner-freebsd-hackers Fri Aug 25 9: 5: 4 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from iclub.nsu.ru (iclub.nsu.ru [193.124.222.66]) by hub.freebsd.org (Postfix) with ESMTP id 79D5B37B43E for ; Fri, 25 Aug 2000 09:04:48 -0700 (PDT) Received: from localhost (fjoe@localhost) by iclub.nsu.ru (8.9.3/8.9.3) with ESMTP id XAA06934; Fri, 25 Aug 2000 23:04:29 +0700 (NSS) (envelope-from fjoe@iclub.nsu.ru) Date: Fri, 25 Aug 2000 23:04:28 +0700 (NSS) From: Max Khon To: "Alexander N. Kabaev" Cc: freebsd-hackers@FreeBSD.ORG, "Bryan K. Ogawa" Subject: Re: Document about threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG hi, there! On Fri, 25 Aug 2000, Alexander N. Kabaev wrote: > There was a bug in -fsjlj-exceptions code generation related to shared > libraries and to best of my knowledge the correct fix has been imported into > the official gcc CVS tree and was merged into FreeBSD some time ago. Are there > any other errors you know about? If there are any simple code snippets which can > demonstrate the problem, I am willing to investigate it further and see if > it can be fixed. -fsjls-exceptions errors should be fixed regardless of whether > FreeBSD is going to switch to DWARF scheme or not. 4.x-STABLE is here to stay > for quite some time and I doubt that it will ever be changed to use DWARF > unwinding. this is definitely not the case with shared libraries -- I know about that bug and the fix was merged to FreeBSD CVS source tree somewhere around beginning of this year. unfortunately I have no simple code snippets and have no time to investigate it further. but I have an application that demonstrates this bug: Reactor_Exceptions_Test from ACE wrappers (you can get ACE wrappers from http://www.cs.wustl.edu/~schmidt/). the test itself is quite simple snippet but you will need to build ACE to run it. please look at #413 and #258 in gcc GNATS. all that I found is that emitted setjmp got optimized during flow analysis stage in such way that when exception is raised execution continues in try { } block (yes, again) instead of place where decision is taken in which catch { } block the execution should be continued. I do not know about any other 2.95.2 bugs. /fjoe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message