Re: A shared version of libgcc

[Richard Henderson <rth at cygnus dot com>]

On Mon, May 01, 2000 at 06:07:49PM +0200, Mark Kettenis wrote:
> 1. Simple utility functions without interdependencies or access to
>    global variables[1].  Examples are __ashldi3, __udivmoddi4.
[...]
>    Assuming that these functions contain no serious bugs, it is
>    absolutely no problem if more than one (potentially different) copy
>    of these functions is used in one program.  Most of these functions
>    are small, so a slight increase in the size of binaries won't be
>    noticed.  Therefore these functions can stay in a static library if
>    we can control re-exporting these functions from shared libraries.

But if we need a shared libgcc for another reason, there's no
reason not to have them in libgcc.so as well.

>    It worries me quite a bit to see that the module containing the
>    frame functions references several of the pthreads functions.  This
>    means that libgcc is tied to a particular implementation of those
>    functions.  This isn't too bad while libgcc is a static library,
>    but could lead to all kinds of badness if libgcc is turned into a
>    shared library, and used in multithreaded libraries.

Eh?  I assume you mean multithreaded programs using a different
pthreads implementation.  But if you've got multiple pthreads
implementations running around your system, doesn't that imply
you've got other configuration problems as well?

This doesn't sound to me like something that we should be
realistically concerned about.

>  * Put those symbols in a shared library, and link all shared
>    libraries and programs that use any of those symbols against this
>    library.  Finding out whether to link with the shared libgcc or not
>    might be tricky.

I posted a possible scheme for this yesterday:

  http://gcc.gnu.org/ml/gcc/2000-04/msg00782.html

>  * On ELF systems, we might include the frame functions in shared
>    libraries that need them (i.e. those that actually use exception
>    handling), but set DT_AUXILIARY to a shared library containing the
>    frame functions.  This will allow things to work if the shared
>    libgcc isn't found, but it only works if those libraries re-export
>    the frame functions and if programs linked with that library do not
>    contain the frame functions.

I don't see that this buy's us anything, just makes problems exceedingly
wierd and hard to diagnose. 

Consider the __register_frame_info plus __register_frame_info_2 coordination
problem.  A real implementation of __r_f_i exists in libfoo.so with
DT_AUXILIARY set appropriately.  A real implementation of __r_f_i and
__r_f_i_2 exists in libbar.so, also with DT_AUXILIARY set.  Consider the
case of libfoo before libbar in the symbol search path.  If libgcc.so
exists, then both libfoo and libbar defer to the libgcc implmementation,
and since libgcc can coordinate the two implementations, all is well.  If
libgcc.so does not exist, then the libfoo and libbar cannot defer the
implementation, the implementations of __r_f_i and __r_f_i_2 come from
different dsos, and coordination does not happen.

The really insidious part of this failure is that, because of the nature
of DT_AUXILIARY, ld.so does not report any sort of error, and the same
application will work on one system but mysteriously fail on another. 
Contrast this with the current situation in which the application with
miscommunicating dsos will fail on all systems.

>  * On ELF systems where we have some control over libc, we can put the
>    frame functions in libc, and set DT_AUXILIARY for libc to a shared
>    libgcc.  That way programs and shared libraries that are linked
>    against libc do not have to be explicitly linked against a shared
>    libgcc, whereas we leave the option open to install a shared libgcc
>    if the frame functions will ever need to be changed.

At the point __r_f_i_2 is introduced, applications that use that
interface have to start linking against libgcc.so directly.  Either
that or libc has to be rebuilt to include them, at which point
DT_AUXILIARY doesn't do you any good at all.

DT_AUXILIARY as I see it is basically only good for selecting cpu-specific
implementations of standard functions.

> And what about the C++ specific symbols?  Since we control libstdc++,
> we have some additional flexibility here:
> 
>  * Keep those in a static library.  If they're also included in
>    libstdc++ this static library will only be used for C++ programs
>    that don't use the standard C++ library.
> 
>  * Include those symbols in libstdc++ and link all C++ programs
>    against libstdc++.
> 
>  * Include those symbols in a special C++ runtime shared library.
> 
>  * Include those symbols in both libstdc++ and the special C++ runtime
>    shared library.  That way one doesn't have to distribute two
>    libraries for C++ programs that use the standard C++ library.

All of these are reasonable, from what little I know of what's
involved with the C++ support in libgcc.  What to do with this
stuff is a question for the G++ and libstdc++-v3 teams to work out.

> In order to avoid GCC 3.0 to depend on an
> unreleased version of the GNU C Library, planning ahead is probably
> essential.

Indeed.

> Since glibc-2.1, all these symbols are versioned (their version name
> is GLIBC_2.0).  It is not possible to remove those symbols from libc.

Yes it is, actually.  But only by coordinating with libgcc.so.
More later.

> However, it might be possible to (ab)use symbol versioning to make
> sure that new programs don't pick them up from libc.so[2].  But I don't
> think it is worth the trouble doing this for the symbols in class 1.
> 
> The frame functions pose a bigger problem, since their presece in libc
> will make it difficult to make sure that the newest version of those
> functions is used at all times.

A solution is definitely required for the frame functions.  The
couple o symbols in class 1 can just ride along on the coattails.

The solution I had in mind is

  (a) For systems currently using glibc, make sure libgcc.so exports
      symbols with the same version tags that glibc currently does.
  (b) Remove the symbols from libc.so and link libc.so against libgcc.so.
      No DT_AUXILIARY, just a straight DT_NEEDED.

This preserves backwards compatibility with old binaries because all
applications which depended on libc.so now pull in libgcc.so indirectly.
Also, libgcc.so is inserted at the appropriate place in the symbol 
search path, so that the symbols which previously resolved to libc.so
now resolve to libgcc.so.



r~