Hello,

To address

  /* The AIX linker will discard static constructors in object files if
     nothing else in the file is referenced [...] */

collect2 on AIX builds the ctor/dtor tables from an explicit scan of
all the objects and libraries.

The scan actually also considers frame tables, so we end up dragging
every object with such tables even if the object is not needed at all
for other reasons.

For instance, with mainline on aix 5.3 configured with
-enable-languages=c,c++ --disable-nls --with-cpu=common, we see:

   /* useless.c */
   extern void nowhere ();
   static void useless ()
   {
     nowhere ();
   }

   /* main.c */
   int main ()
   {
     return 0;
   }

   $ g++ -c useless.cc
   $ ar rv libuseless.a useless.o
   ar: creating an archive file libuseless.a
   a - useless.o

   $ g++ -o m main.cc -L. -luseless
   ld: 0711-317 ERROR: Undefined symbol: .nowhere()
   ...
   collect2: ld returned 8 exit status

-Wl,-debug reads:

     List of libraries:
        ./libuseless.a,
     ...
     extern void *x7 __asm__ ("_GLOBAL__F_useless.cc_00000000_03A3E4DF");
     ...
     static void *frame_table[] = {
                &x7,

The "useless" object has been included because of a reference to its
frame tables out of collect2's processing for libuseless.a. 

This behavior is problematic because it might cause the inclusion of
loads of useless objects in general, with two consequences: executables
potentially much larger than needed and unexpected dependencies.

We noticed this while working on DWARF2 exceptions support for Ada
with a static run-time library: almost the full library ends up
included in every executable, causing a significant waste in space and
forcing to systematically link with at least libm.

A possible way to address would be to perform a double scan: the
current one to discover ctors/dtors only, leaving the frame tables
alone, and a second one on the resulting executable (past a first link
phase) to discover the relevant frame tables only.

The obvious drawback is link-time performance, but since there is a
real COFF scanner and we're not using the generic "nm" based scheme,
it might not be that much of an issue. I have no hard data at hand, so
can't really tell at this point.

Thoughts ?

Thanks in advance,

Olivier











Reply via email to