This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Fix failure of g++.dg/other/first-global.C


> > I believe that it's important to maintain symbol name compatibility
> > for constructors.  The way libtool links applications against shared
> > libraries will cause the application to fail at startup if the shared
> > library is replaced and it contains a different exported global symbol.
> 
> As with the other patch, I'd appreciate knowing more about what's going
> on here.  Is libtool generating code to link into the main application
> that calls the global constructors for each of the shared libraries?
> Does that happen only on non-ELF systems?  (I'd think that on ELF
> systems, shared-library initialization is handled by an initialization
> function for the library, run by the dynamic loader.)

Ok, I now understand better what's happening.  With current PA GCC
versions, the bug is limited to HP-UX 10 which still uses collect2 to
generate a table of constructors/destructors for the object being linked.

First look at PR 33772:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33772

You will see that collect2 has introduced dependencies in the symbol
table of various shared libraries for global constructors/destructors
in other libraries.  For example, libguile.sl has dependencies on
constructors for libgcc_s, libgmp_sl, and libltdl, each with appended
version information.  The same occurs for applications when collect2
builds the constructor table for the application and dependent libraries.

The shared library list as shown by chatr does not have the same degree
of version specificity as the library constructors.  Clearly, stripping
the library version from the constructor names generated by collect2
will help in updating from one shared library version to another.

However, I also think it's a bug for collect2 to create dependencies
in a shared library on constructors in other dependent libraries.  I
don't think we have a mechanism to run these constructors when a library
is dynamically loaded/unloaded.  That's why I changed to using the +init
and +fini linker options available in HP-UX 11.

Still, eliminating the constructor symbols from shared libraries won't
resolve the problem (the version string needs removal), but it would
remove some unnecessary dependences (e.g., library changes from needing
a constructor to not needing a constructor).

As far as I know, libtool has no role in generating code to run
constructors.  This is handled solely by collect2.  There are macros
in som.h for the generation and parsing of the dependencies of
dynamically linked executables and shared libraries by collect2.

> > In this patch, I introduce a new function cgraph_build_static_cdtor_1
> > which only encodes the priority if its fourth argument ENC_P is true.
> 
> Should cgraph_build_static_cdtor just never encode the priority for
> things with the DEFAULT_INIT_PRIORITY?

No, that's the first thing I tried.  There are multiple callers of
cgraph_build_static_cdtor (e.g., for gcov coverage).

After the above rethink, it's clear that the only constructor names
that we really need to be concerned about are those created by collect2.
Thus, I probably should withdraw this patch and just change the testcase
for the PR to accept the priority encoded alternative.  This avoids any
possibility of duplicate constructor names.

The patch to change collect2 to strip a version string after ".sl"
is still needed.

Thanks,
Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]