From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22157 invoked by alias); 23 Mar 2008 09:22:33 -0000 Received: (qmail 22147 invoked by uid 22791); 23 Mar 2008 09:22:32 -0000 X-Spam-Check-By: sourceware.org Received: from rv-out-0910.google.com (HELO rv-out-0910.google.com) (209.85.198.184) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 23 Mar 2008 09:22:15 +0000 Received: by rv-out-0910.google.com with SMTP id g11so1342194rvb.56 for ; Sun, 23 Mar 2008 02:22:13 -0700 (PDT) Received: by 10.140.139.3 with SMTP id m3mr1826623rvd.244.1206264133483; Sun, 23 Mar 2008 02:22:13 -0700 (PDT) Received: by 10.141.50.3 with HTTP; Sun, 23 Mar 2008 02:22:13 -0700 (PDT) Message-ID: Date: Sun, 23 Mar 2008 09:22:00 -0000 From: "Shlom Marom" To: gcc-help@gcc.gnu.org Subject: Re: Exception handling on AIX5.3 with gcc 3.4.6 In-Reply-To: <47E47C02.87CF42E5@dessent.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47E29267.AAFEF6F1@dessent.net> <47E47C02.87CF42E5@dessent.net> 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-03/txt/msg00229.txt.bz2 Hi brian, tx a lot for the great answer! Shlom On Sat, Mar 22, 2008 at 5:24 AM, Brian Dessent wrote: > > Shlom Marom wrote: > > > 1. is it relevant also for gcc (not g++) > > If you're asking if there's a problem linking C code with static libgcc > then I would guess it's probably not an issue since you cannot throw or > catch exceptions in C. > > > 2. what is the reason for that? > > I don't know the specific reason for your case, but I can think of > several general reasons why static linking libgcc would be a problem. > > The first is that it creates the possibility for multiple instances of > the unwinder in the final process, each unaware of the other. For > example, suppose you had a main program and a library, each linked > statically to libgcc. Each would register their unwind information > (either .eh_frame FDE tables for DWARF-2, or function contexts for SJLJ, > or whatever) with their own separate copy of the unwinder. If one tried > to throw to the other, the unwinder would not find any handler since it > would be unaware of the registered info from the other module, and would > probably abort/terminate with an uncaught exception. By having libgcc > be a shared object there is only ever one instance shared by all the > modules in the process. > > The other potential issue is that when statically linking the link > editor only selects objects from an archive that contain symbols that > have been referenced by something in the objects it's scanned so far. > All unreferenced objects are discarded. If there were routines > necessary by the unwinder at runtime that are not directly referenced by > user code, they wouldn't be included in the link. I don't know if this > is actually a problem in reality or not, but if it is you might be able > to use -Wl,--whole-archive (or whatever the AIX linker calls it if not > using the GNU linker) to work around it. > > Another reason could simply be that the initialization of the unwinder > and registration of unwind info requires hooks only available to a > shared library, such as the DT_INIT/DT_FINI dynamic tags (corresponding > to the .init and .fini sections.) > > > 3. is it common to distribute a gcc llib with your product? do you > > know anyhing about the licensing issue? > > To answer that question look at the code. Every file has a copyright > header. In the case of libgcc you should look at gcc/libgcc2.{c,h}, one > or more of gcc/unwind*, and probably one or more gcc/gthr*. The > specific files that get linked into libgcc depend on details of the > target. > > But I'll save you the work. libgcc is licensed under GPLv2 with the > "runtime exception" clause, which is intended to allow unrestricted use > of the gcc libraries when linked with your code -- just using gcc to > build something doesn't require that thing to be GPL. You can think of > it another way: you're already distributing libgcc code with your > product (statically linked into it) so switching to shared libgcc > doesn't really change the situation. But as with all things legal, > consult a lawyer if you want real definitive answers, et cetera. > > As to whether it's common to distribute libgcc, I guess that varies > widely. If you're talking about linux then it would be hard to find a > system without a shared copy of libgcc already on the system so it's > usually not necessary to distribute it. However, there can be problems > if the compiler you use contains a more recent version of libgcc than > what's on the user's system so I suppose there's always some need for > distributing libgcc if it's not possible to statically link it. In > general though distributing binary software is a whole separate > headache, spanning much more than just libgcc. > > Brian >