[PATCH] shared libgcc spec: AIX EH fix

[David Edelsohn <dje at watson dot ibm dot com>]

	The following patch fixes the AIX exception handling problem,
which in turn resolves many g++ and libstdc++-v3 testcase failures.

	The patch changes libgcc_spec to not link against the static
libgcc.a library if -shared is present.  That's the only change.

	Currently, the spec looks like:

%{!shared-libgcc:%{!static-libgcc:%{shared:-lgcc_s -lgcc}}}
%{!shared-libgcc:%{!static-libgcc:%{!shared:-lgcc -lgcc_eh}}}

the revised spec looks like:

%{!shared-libgcc:%{!static-libgcc:%{shared:-lgcc_s}}}
%{!shared-libgcc:%{!static-libgcc:%{!shared:-lgcc -lgcc_eh}}}

	On AIX, collect2 scans static libraries because CSECTS may be
garbage collected away if not referenced in the link, but the dependency
may not be apparent prior to scanning for constructors, destructors, and
Dwarf2 EH Frames.

	The problem is that the DIVMOD functions in libgcc.a contain
exception handling Frame information.  When collect2 is used to create a
shared library which implicitly is linked with static libgcc.a, it scans
libgcc.a, finds Frame information, and adds that to the Frame information
for the shared object it is generating.  However, those functions and
Frame information are provided by the shared libgcc, which means that the
shared object being created includes Frame information for another shared
library in the array of EH information it registers.  Those Frame entries
from the other shared library are external references satisfied at
runtime.

	When the Dwarf2 EH algorithm searches the shared object for Frame
address ranges, it finds the DIVMOD Frames.  Depending on the order in
which the shared objects are searched and the addresses at which they are
loaded, the ranges may appear to be overlapped, which specifically is not
allowed by the seen_objects sort.  The algorithm may not find a handler
for the PC of the exception and EH fails.

	I do not see any compelling reason to link shared objects against
static libgcc.a.  _eprintf and __gcc_bcmp are deprecated.  Anyone who can
figure out how to get -a/-ax basic-block profiling to work with tcov and
gprof, and needs to basic-block profile a shared library, surely can
figure out how to link the shared library with the static _bb routines.

	With the appended patch, shared libraries never are linked against
static libgcc.a, it never is scanned, and the external Frame information
never is registered by the shared library being created.

Thanks, David

	* gcc.c (init_gcc_spec): Do not link with static libgcc.a if
	gcc invoked with -shared.

Index: gcc.c
===================================================================
RCS file: /cvs/gcc/egcs/gcc/gcc.c,v
retrieving revision 1.281
diff -c -p -r1.281 gcc.c
*** gcc.c	2001/12/23 16:07:06	1.281
--- gcc.c	2001/12/26 22:55:05
*************** init_gcc_specs (obstack, shared_name, st
*** 1439,1445 ****
  #ifdef LINK_EH_SPEC
    sprintf (buffer, "%s}}}", static_name);
  #else
!   sprintf (buffer, "%s %s}}}", shared_name, static_name);
  #endif
    obstack_grow (obstack, buffer, strlen (buffer));
    /* Otherwise, use the static version.  */
--- 1439,1445 ----
  #ifdef LINK_EH_SPEC
    sprintf (buffer, "%s}}}", static_name);
  #else
!   sprintf (buffer, "%s}}}", shared_name);
  #endif
    obstack_grow (obstack, buffer, strlen (buffer));
    /* Otherwise, use the static version.  */

===============================================================================
David Edelsohn                                      T.J. Watson Research Center
dje@watson.ibm.com                                  P.O. Box 218
+1 914 945 4364 (TL 862)                            Yorktown Heights, NY 10598