gcc-apple and C++ exceptions
 

Hi all - first, a little test program, test.cpp:
----
#include <iostream>
#include <stdexcept>

int main(int argc, char* argv[])
{
using namespace std;

try
{
throw runtime_error("runtime_error");
}
catch (const std::runtime_error& re)
{
cout << "Caught runtime_error: " << re.what() << endl;
}

return 0;
}
----

When I compile this with my XCode g++ (gcc version 4.2.1 (Apple Inc.
build 5659)) , it works as expected:
$ /usr/bin/g++ -o test test.cpp
$ otool -L ./test
./test:
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 125.0.1)
$ ./test
Caught runtime_error: runtime_error

However, with my gentoo-alt gcc-apple g++ (gcc version 4.2.1 (Gentoo
4.2.1_p5659, Apple Inc. build 5659):
$ g++ -o test test.cpp
$ otool -L ./test
./test:
/Users/mattm/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/libstdc++.6.dylib
(compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 125.0.1)
$ ./test
terminate called after throwing an instance of 'std::runtime_error'
Abort trap

I've tried a few flags (-fexceptions, etc.), but I still can't get any
C++ code compiled with the gentoo-alt gcc-apple to catch exceptions
properly. Any ideas?


Matt.

gcc-apple and C++ exceptions
 

On 27-05-2010 09:23:30 +1000, Matt Michalowski wrote:
> Hi all - first, a little test program, test.cpp:
[snip]
> When I compile this with my XCode g++ (gcc version 4.2.1 (Apple Inc.
> build 5659)) , it works as expected:
> $ /usr/bin/g++ -o test test.cpp
> $ otool -L ./test
> ./test:
> /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
> current version 7.9.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 125.0.1)
> $ ./test
> Caught runtime_error: runtime_error
>
> However, with my gentoo-alt gcc-apple g++ (gcc version 4.2.1 (Gentoo
> 4.2.1_p5659, Apple Inc. build 5659):
> $ g++ -o test test.cpp
> $ otool -L ./test
> ./test:
> /Users/mattm/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/libstdc++.6.dylib
> (compatibility version 7.0.0, current version 7.9.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> current version 125.0.1)
> $ ./test
> terminate called after throwing an instance of 'std::runtime_error'
> Abort trap
>
> I've tried a few flags (-fexceptions, etc.), but I still can't get any
> C++ code compiled with the gentoo-alt gcc-apple to catch exceptions
> properly. Any ideas?

Compare the sizes of both programs. We noticed this problem a while
ago, because the linker (ld) is crashing on Snow Leopard when it tries
to issue an error (it throws it). I don't recall the exact details any
more, but for some reason if you do a static link, it does work. The
responsible objects seem to be not working when invoked dynamically or
something. heiko_ actually dived into it, but we were never able to
solve the problem. (And it doesn't show up on Tiger and Leopard.)


--
Fabian Groffen
Gentoo on a different level

gcc-apple and C++ exceptions
 

On Thu, 27 May 2010 08:26:50 +0200
Fabian Groffen <grobian@gentoo.org> wrote:

> On 27-05-2010 09:23:30 +1000, Matt Michalowski wrote:
> > Hi all - first, a little test program, test.cpp:
> [snip]
> > When I compile this with my XCode g++ (gcc version 4.2.1 (Apple Inc.
> > build 5659)) , it works as expected:
> > $ /usr/bin/g++ -o test test.cpp
> > $ otool -L ./test
> > ./test:
> > /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
> > current version 7.9.0)
> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> > current version 125.0.1)
> > $ ./test
> > Caught runtime_error: runtime_error
> >
> > However, with my gentoo-alt gcc-apple g++ (gcc version 4.2.1 (Gentoo
> > 4.2.1_p5659, Apple Inc. build 5659):
> > $ g++ -o test test.cpp
> > $ otool -L ./test
> > ./test:
> > /Users/mattm/gentoo/usr/lib/gcc/x86_64-apple-darwin10/4.2.1/libstdc++.6.dylib
> > (compatibility version 7.0.0, current version 7.9.0)
> > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> > current version 125.0.1)
> > $ ./test
> > terminate called after throwing an instance of 'std::runtime_error'
> > Abort trap
> >
> > I've tried a few flags (-fexceptions, etc.), but I still can't get
> > any C++ code compiled with the gentoo-alt gcc-apple to catch
> > exceptions properly. Any ideas?
>
> Compare the sizes of both programs. We noticed this problem a while
> ago, because the linker (ld) is crashing on Snow Leopard when it tries
> to issue an error (it throws it). I don't recall the exact details
> any more, but for some reason if you do a static link, it does work.
> The responsible objects seem to be not working when invoked
> dynamically or something. heiko_ actually dived into it, but we were
> never able to solve the problem. (And it doesn't show up on Tiger
> and Leopard.)
>
>

Yeah, darwin10 changed the lookup of global program data (such as
exceptions). Where keymgr was used before, it seems that libunwind
(unfortunately closed) is used instead. The problem relies in removing
those libunwind .eh_frame setup calls from our ld64 to make it compile.
Thus we probably remove the proper setup for libSystem's lookup of
exception data through a properly setup .eh_frame.

__keymgr_initializer() in [1] is pretty nice commented:

" /* On Mac OS X 10.6, unwinding is down by libunwind in
libSystem.B.dylib */"

and

" /* On Mac OS X 10.6, libunwind in libSystem.dylib implements all
unwinding functionality. */ /* libunwind does not use keymgr, so there
is no need to maintain KEYMGR_GCC3_LIVE_IMAGE_LIST */ /* in sync with
dyld's list of images. But there might be some i386 or ppc
applications that */ /* carry around there own copy of the unwinder
(from libgcc.a) and need KEYMGR_GCC3_LIVE_IMAGE_LIST. */"

The second part regarding libgcc.a could probably also be what grobian
described -- maybe static(-libgcc) programs have their own unwinder
onboard and thus magically work.

Looks like another open c-project of Apple moved to a (yet) closed
c++-overkill project.

I wonder if specifying "-static-libgcc" or "-mmacosx-version-min=older
macos version" for the c++ program to be compiled would make things
work for now? Testers welcome ;)


-- Heiko


[1] http://opensource.apple.com/source/keymgr/keymgr-22/keymgr.c