Exception handling on AIX5.3 with gcc 3.4.6

Exception handling on AIX5.3 with gcc 3.4.6

[Shlom Marom]

[-- Attachment #1: Type: text/plain, Size: 3654 bytes --]

Hi guys,

I have some weird problem with exception handling on AIX (gcc 3.4.6
with AIX5.3), which I couldn't find any solution for in the web.

-----------------------------
Problem description:
-----------------------------
When throwing an exception of some derived object type, catch it,
re-throw it and then try to catch it by the base object, the program
gets segmentation fault instead of being caught by the relevant catch.
BUT, please not to the weirdest problem:
If I compiled the program with shared lib-gcc and with the pthread
libstdc++ - everything works fine and also the base exception is being
caught as it should.

*Attached here a very small cpp file that contains a simple, for your
convenient, although I will also paste the code in the email body…

-----------------------------
The code:
-----------------------------
#include <stdio.h>
void fun(void)
{
        printf("in fun() - before throwing int...\n");
        throw 1;
}
int main(void)
{
    try
    {
        try
        {
                fun();
        }
        catch(int i)
        {
                printf("catch int exception: %d, and re-throw...\n", i);
                throw;
        }
    }
    catch (...)
    {
       printf("the re-throw was caught...\n");
    }
    return 0;
}

----------------------------------------------------
Compilation (and link) commands:
----------------------------------------------------
Shared linking: gcc -o tester_shared main.cpp -pthread -I.
-shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++
Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads
-pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc
-print-file-name=libstdc++.a` -O
*** `gcc -print-file-name=libstdc++.a` returns
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../libstdc++.a

----------------------------------------------------
Executables ldd output:
----------------------------------------------------
Shared linking:
--------------------
$ldd ./tester_shared
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../libgcc_s_pthread.a(shr.o)
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../pthread/libstdc++.a(libstdc++.so.6)
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/lib/libpthread.a(shr_comm.o)
./tester_shared
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)

Static linking:
--------------------
$ldd ./tester_static
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/lib/libpthread.a(shr_comm.o)
./tester_static
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)

----------------------------------------------------
Executables output:
----------------------------------------------------
Shared linking:
--------------------
in fun() - before throwing int...
catch int exception: 1, and re-throw...
the re-throw was caught...

Static linking:
--------------------
in fun() - before throwing int...
catch int exception: 1, and re-throw...
Segmentation fault (core dumped)


----------------------------------------------------
My purpose:
----------------------------------------------------
I need to find a way to fully support exception handling and
statically link libgcc, since I don't want to distribute it with my
libs and executables, as part of my products


----------------------------------------------------
Notes:
----------------------------------------------------

1. The same problem happens when instead of re-throw int and catch
(...) , you re-trow derived and catch base...
2. The same code works fine on other UNIX os, such as Linux (RHEL,
Fedora, etc.…)


Thanks in advanced,

Shlom Marom

[-- Attachment #2: minimal_main.cpp.cpp --]
[-- Type: text/plain, Size: 461 bytes --]

#include <stdio.h>

void fun(void)
{
        printf("in fun() - before throwing int...\n");
        throw 1;
}

int main(void)
{
    try
    {
        try
        {
                fun();
        }
        catch(int i)
        {
                printf("catch int exception: %d, and re-throw...\n", i);
                throw;
        }
    }
    catch (...)
    {
        printf("the re-throw was caught...\n");
    }
    return 0;
}

Re: Exception handling on AIX5.3 with gcc 3.4.6

[Brian Dessent]

[ Don't CC: a million different @gcc.gnu.org lists, the whole point of
having them separate is so that people's mailboxes aren't flooded with
mails, which you render ineffective by sending a copy to every list. 
gcc@ especially is about development of gcc not help using it. ]

Shlom Marom wrote:

> If I compiled the program with shared lib-gcc and with the pthread
> libstdc++ - everything works fine and also the base exception is being
> caught as it should.
> ...
> Shared linking: gcc -o tester_shared main.cpp -pthread -I.
> -shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++
> Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads
> -pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc

A shared libgcc is pretty much required for proper exception handling, I
just don't think you're going to be able to get around that.  This
should hold true for pretty much every target so the fact that it works
with static libgcc on Linux is by accident, or perhaps luck.

Brian

Re: Exception handling on AIX5.3 with gcc 3.4.6

[David Edelsohn]

>>>>> Shlom Marom writes:

> I need to find a way to fully support exception handling and
> statically link libgcc, since I don't want to distribute it with my
> libs and executables, as part of my products

	One cannot build a static C++ application that uses exceptions and
is built with G++ on AIX.

David

Re: Exception handling on AIX5.3 with gcc 3.4.6

[Shlom Marom]

hi,
tx for your answer.
1. is it relevant also for gcc (not g++)
2. what is the reason for that?
3. is it common to distribute a gcc llib with your product? do you
know anyhing about the licensing issue?


tx.
shlom


On 3/20/08, Brian Dessent <brian@dessent.net> wrote:
> [ Don't CC: a million different @gcc.gnu.org lists, the whole point of
> having them separate is so that people's mailboxes aren't flooded with
> mails, which you render ineffective by sending a copy to every list.
> gcc@ especially is about development of gcc not help using it. ]
>
> Shlom Marom wrote:
>
> > If I compiled the program with shared lib-gcc and with the pthread
> > libstdc++ - everything works fine and also the base exception is being
> > caught as it should.
> > ...
> > Shared linking: gcc -o tester_shared main.cpp -pthread -I.
> > -shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++
> > Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads
> > -pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc
>
> A shared libgcc is pretty much required for proper exception handling, I
> just don't think you're going to be able to get around that.  This
> should hold true for pretty much every target so the fact that it works
> with static libgcc on Linux is by accident, or perhaps luck.
>
> Brian
>

Re: Exception handling on AIX5.3 with gcc 3.4.6

[Brian Dessent]

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

Re: Exception handling on AIX5.3 with gcc 3.4.6

[Shlom Marom]

Hi brian,

tx a lot for the great answer!

Shlom



On Sat, Mar 22, 2008 at 5:24 AM, Brian Dessent <brian@dessent.net> 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
>

Re: Exception handling on AIX5.3 with gcc 3.4.6

[Ian Lance Taylor]

Brian Dessent <brian@dessent.net> writes:

> Shlom Marom wrote:
>
>> If I compiled the program with shared lib-gcc and with the pthread
>> libstdc++ - everything works fine and also the base exception is being
>> caught as it should.
>> ...
>> Shared linking: gcc -o tester_shared main.cpp -pthread -I.
>> -shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++
>> Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads
>> -pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc
>
> A shared libgcc is pretty much required for proper exception handling, I
> just don't think you're going to be able to get around that.  This
> should hold true for pretty much every target so the fact that it works
> with static libgcc on Linux is by accident, or perhaps luck.

Brian's answer is in general correct.  However, there is a case where
it works.  You can use -static-libgcc when throwing exceptions across
shared library boundaries if:

1) gcc is configured to use unwind-dw2-glibc-fde.c instead of
   unwind-dw2-glibc.c (this happens on GNU/Linux systems and some
   others--look for uses of t-linux or t-libunwind-elf in
   gcc/config.gcc).

2) gcc is configured to pass --eh-frame-hdr to the linker (this
   happens automatically if the linker available when configuring gcc
   supports this option).

3) The executable and all shared libraries were in fact built by a gcc
   which passes --eh-frame-hdr to the linker.

4) Your C library has a working copy of dl_iterate_phdr (this is true
   for recent versions of glibc on GNU/Linux).

If all those conditions are true, then unwind information does not
need to be registered at program startup.  Instead, the unwind library
will find it at runtime using dl_iterate_phdr to look for
PT_GNU_EH_FRAME segments created by the linker.  And in that case
-static-libgcc will work.

Ian