Re: Libgcc symbols

[Joern Rennecke <amylaar at cambridge dot redhat dot com>]

> This does raise a question in my mind: if a target defines additional
> support routines in a lib1funcs.asm, how do they get into the symbol
> map?

More urgently: how do you keep crap out of the symbol map?  The
multi-precision arithmetic in libgcc.c is not much more than a proof
of concept, and results in very poor code.  Even if you need to write
an out-of-line piece of code, you can generally do much better doing so
in optimized assembler.  But the libgcc2.c versions are in the way.
For a static library, that is not an issue: you make the compiler call
a function with a different name, which is coded in lib1funcs.asm
(sometimes even with a streamlined calling convention).  The libgcc2.c
version gets still compiled to a junk .o file, but it only costs a few
bytes of disk space in the static library.
But this junk shouldn't be included in a shared library - it's just bloat.
Likewise, even where the multiprecision arithmetic is still used, this is
likely only because nobody has cared much about its performance so far.
When someone does, you want to delete that function and swap it for a
lib1funcs.asm one.  So we should only compile these functions for the
static libgcc.a (unless the target system has no concept of static
libraries).

It's much easier to add symbols than to delete them from a shared library,
so why not start with the symbols we really do want to he shared on only
put those into a shared library?