From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 516 invoked by alias); 4 Aug 2008 15:26:29 -0000 Received: (qmail 508 invoked by uid 22791); 4 Aug 2008 15:26:29 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 04 Aug 2008 15:25:38 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m74FPZrI025842; Mon, 4 Aug 2008 11:25:36 -0400 Received: from localhost.localdomain (vpn-14-28.rdu.redhat.com [10.11.14.28]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m74FPRVo010930; Mon, 4 Aug 2008 11:25:33 -0400 Message-ID: <48971F5D.4090508@redhat.com> Date: Mon, 04 Aug 2008 15:26:00 -0000 From: Andrew Haley User-Agent: Thunderbird 2.0.0.16 (X11/20080707) MIME-Version: 1.0 To: Barry Andrews CC: gcc-help@gcc.gnu.org Subject: Re: Mixing exception handling libraries with non exception handling References: <489714C9.6010109@gmail.com> <48971938.40203@redhat.com> <48971DE4.90804@gmail.com> In-Reply-To: <48971DE4.90804@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-08/txt/msg00033.txt.bz2 Barry Andrews wrote: > So, since it is a runtime thing, I would think I would be able to > control this somehow when my library is loaded. Do you know how > exception handling is turned off anyway? I mean... I can load another C > library ( libc for example ) which obviously does not have exception > handling and it doesn't interfere with my C++ exceptions. Unwinder data for exceptions is generated by the compiler. Depending on your platform, libc (or at least some of it) may well be compiled with -fexceptions. It should only matter if a stack frame belonging to the C library is active on the stack at the time the exception is thrown. In other words, if you throw from your code, and catch from your code, and no routine in the library is in-between, exceptions should still work. Andrew. > Andrew Haley wrote: >> Barry Andrews wrote: >> >> >>> I have a 3rd party library ( which I'll call X ) which I believe was >>> compiled with exception handling disabled. Then I have my C++ library >>> which does have exception handling. When I load the X library first into >>> a process, then load my library in the same process, exception handling >>> becomes disabled and the abort() function is called. from unwind-dc2.c >>> if I try to throw an exception in my code. This only happens if I load >>> the X library first. I don't have any control over the X library, i.e. I >>> cannot recompile it. >>> >>> Has anyone run into this before? >> >> Yes. >> >> >>> Is there some compiler option in gcc or >>> #define I should have to keep exception handling enabled when I load my >>> library? >>> >> >> No. >> >> >>> It appears that this is some sort of runtime thing. >>> >> >> Yes. Throwing an exception uses unwinder data which the runtime >> library uses to unwind frames on the stack when an exception is >> thrown. No unwinder data and you can't throw an exception; it >> can't be helped. >> >> Andrew. >> >> > >