This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
GCC 3.2.3, exceptions and shared libraries on AIX 4 and 5 ...
- From: "Frank Patz" <fp at contact dot de>
- To: <gcc-help at gcc dot gnu dot org>
- Date: Thu, 7 Aug 2003 18:40:10 +0200
- Subject: GCC 3.2.3, exceptions and shared libraries on AIX 4 and 5 ...
- Organization: CONTACT Software GmbH
Hi!
Throwing from a shared library fails on AIX 4.3.3 and 5.1.
I've seen this problem described quite a couple of times here and
elsewhere, but it either had been claimed to be fixed or postings
have been left unanswered. For me, it looks like the problem is a
function of the code size: we can reproduce this with a small
testcase that works when left small, and fails when linked with
larger shared libs (ACE/TAO in our case) -- and it fails even
before any code from the larger libs has been called. That seems
consistent with reports of other people regarding this problem:
small cases work, big ones fail.
Here is a stack trace for reference:
#0 0xd0014af8 in pthread_kill ()
from /usr/lib/libpthreads.a(shr_xpg5.o)
#1 0xd0013eb0 in _p_raise ()
from /usr/lib/libpthreads.a(shr_xpg5.o)
#2 0xd0187930 in raise ()
from /usr/lib/libc.a(shr.o)
#3 0xd018039c in abort ()
from /usr/lib/libc.a(shr.o)
#4 0x20b4fa70 in uw_init_context_1
(context=0x2ff21ec8, outer_cfa=0x2ff22738, outer_ra=0x20a876e8)
at ../../../../../src/gcc-3.2.3-wo-binutils/gcc/unwind-dw2.c:1125
#5 0x20b4fef4 in _Unwind_RaiseException (exc=0x21102f88)
at ../../../../../src/gcc-3.2.3-wo-binutils/gcc/unwind.inc:84
#6 0x20a876e8 in __cxa_throw (obj=0x0, tinfo=0xffffffff,
dest=Cannot access memory at address 0xffffffff)
at ../../../../../../../src/gcc-3.2.3-wo-binutils/\
libstdc++-v3/libsupc++/eh_throw.cc:72
We've already debugged down into uw_init_context_1(), and see it
fail since uw_frame_state_for() returned 0. The unwinding information
seems to be lost or destroyed.
We've tested all kinds of voodoo recipes: -pthread vs. not threaded,
building shared libs the AIX way (.a containing shr.o) vs. building
.so files, something weird related do "chmod a+x,o-r"ing the shared
libs, but nothing helped: the problem simply is a function of the
code size.
We're willing to explore this further if nobody knows a resolution
(or an explanation at least), but it would be helpful if some guru
could shed some light on the inner secrets of EH, how it interferes
with collect2, just a handful of cues, how it is *supposed* to work,
so we can start looking at it a little bit more competently ...
FYI, our gcc configuration (gcc 3.2.3), we use AIX's as and ld:
configure --enable-shared --enable-threads --disable-multilib\
--disable-aix64
Thanks,
- frank