libgcc_s.so.1 exception handling behaviour depending on glibc version

[Stephan Bergmann]

Hi all,
I experience the following problem on Linux x86:
I have one version of GCC, call it C1, compiled on a glibc 2.2 (plain 
2.2, that is) machine.  (It happens to be GCC 3.4.1, but the exact 
version is probably irrelevant.)  This build includes a version of 
libgcc_s.so.1.

Additionally, I have a second version of GCC, call it C2, compiled on a 
glibc 2.3 machine.  (For C2, I tested various versions of GCC, from 
3.3.x to 4.0.x, and again the exact version is probably irrelevant.) 
This build includes another version of libgcc_s.so.1.

Now, I have a C++ program consisting of an executable main, built from 
main.cc:

  void f();
  int main() { f(); }
and linked against a shared library libf.so, built from f.cc:
  void f() { try { throw 1; } catch (int) {} }
If I build both main and libf.so with C1, and execute the program so 
that it uses C1's libgcc_s.so.1, it works.

If I build main with C1, and libf.so with C2, and execute the program so 
that it uses C1's libgcc_s.so.1, it aborts.

If I build main with C1, and libf.so with C2, and execute the program so 
that it uses C2's libgcc_s.so.1, it works.

It appears that C1's libgcc_s.so.1 is not compatible with C2's.  I did 
not dig too deep into the code, but it appears that libgcc_s.so.1's 
_Unwind_Find_FDE (in gcc/unwind-dw2-fde-glibc.c) differs depending on 
whether or not [EMAIL PROTECTED] is available in glibc at the 
time the compiler is built; this leads to _Unwind_Find_FDE (called 
indirectly from _Unwind_RaiseException, from f.cc's throw 1) either 
returning null (and the process aborts) or returning non-null (and the 
program works ok).

In an earlier thread 
(<http://gcc.gnu.org/ml/gcc/2003-09/msg00052.html>), I learned that 
libgcc_s.so.1 changes incompatibly (though backwards compatibly) along 
the dimension of GCC versions (e.g., from GCC 3.2 to 3.3 to 4.0, etc.). 
 Can anybody confirm that it is known and intended that libgcc_s.so.1 
also changes incompatibly (though backwards compatibly, as it appears) 
along the dimension of glibc versions used to build GCC (e.g., from 
glibc 2.2 to 2.2.4 to 2.3 etc.)---or is what I describe above to be 
considered a bug?

Thanks,
-Stephan