Re: [libunwind] libunwind in gcc

[James E Wilson]

On Wed, 2004-09-22 at 09:23, Tommy Hoffner wrote:
> Does anybody know the current status on gcc concerning libunwind. There 
> was a message regarding --enable-libunwind-exceptions (is it a command 
> line option?), which i can't find in the documentation for gcc 3.3.3 or 
> 3.4.2.

--enable-libunwind-exceptions is a configure option.  There is a
corresponding negative option --disable-libunwind-exceptions.

There are a number of different schemes for gcc libunwind support.  How
this stuff works depends on exactly which gcc version and patches you
have.  It is probably best to check your gcc carefully.

In gcc sources with the current scheme, gcc contains its own libunwind
library that contains all of the gcc routines that implement the unwind
API.  You can then choose which libunwind library you want, by either
linking with the Mosberger libunwind or the gcc libunwind.  If you use
the --with-system-libunwind configure option, then the gcc libunwind
library will not be built, and the Mosberger libunwind will be used
always.  This new scheme is in gcc mainline, which will eventually be
gcc-4.0, and is in the yet unreleased gcc-3.4.3.  It is possible that
some system vendors may have patched this into the gcc that they
distribute.

In the previous scheme, gcc built its unwind API routines into the
libgcc library, which is always linked into all executables by default. 
If gcc detected an installed libunwind at configure time, or if you used
the --enable-libunwind-exceptions option, the gcc unwind API routines
would not be built into the gcc library.  This is used in gcc-3.3.x and
gcc-3.4.[012].

This scheme could sometimes lead to trouble.  You could end up with two
libgcc libraries, one with the unwind routines and one without.  If you
then mixed shared libraries linked against the two different libgccs, it
would be possible to end up in a situtation where a library that needed
a unwind-ful libgcc accidentally got the unwind-less libgcc, and the
result would be dynamic linker errors.  If you are careful, you should
be able to avoid this problem.

> What I'm specicially interested in is support for libunwind in the c++ 
> libraries (i.e. using libunwind when handling throw/catch).
> Is it in there? from which version? is it default behavior (i.e. is it 
> likely to be turned on in prebuilt packages like debian libstdc++? or am 
> I expecting way to much :-)

You would have to ask the system vendors.

I know that David Mosberger is working with the debian developers.  They
were working on getting an official debian libunwind package out.  I
don't know the status of that.  They will probably migrate libunwind to
the new scheme very soon now, though it may be a while before they have
a gcc that uses the new scheme, as we the gcc developers haven't
released one yet.