Pulling libgcc compat symbols out of libgcc.a

[Zack Weinberg <zackw at panix dot com>]

In https://sourceware.org/ml/libc-alpha/2017-05/msg00453.html I asked
why the architectures that need to put exposed compatibility versions
of libgcc symbols into libc.so don't get their definitions from
libgcc.a (or, in other words, why ./sysdeps/wordsize-32/divdi3.c
exists in our source tree), and after a bit of confusion Joseph
replied that current libgcc defines these as hidden, unversioned
symbols and he didn't know any way to fix that.

Well, it *appears* that it can be fixed with objcopy:

$ ar x libgcc.a divdi3.o  # this is gcc6/i386 libgcc.a
$ readelf -s _divdi3.o

Symbol table '.symtab' contains 7 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 SECTION LOCAL  DEFAULT    2
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000     0 SECTION LOCAL  DEFAULT    5
     6: 00000000   362 FUNC    GLOBAL HIDDEN     1 __divdi3

$ objcopy --add-symbol __divdi3@GLIBC_2.0=.text:__divdi3,function,global \
    --strip-symbol __divdi3 _divdi3.o _divdi3_g.o
$ readelf -s _divdi3_g.o

Symbol table '.symtab' contains 7 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 SECTION LOCAL  DEFAULT    1
     2: 00000000     0 SECTION LOCAL  DEFAULT    2
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000     0 SECTION LOCAL  DEFAULT    5
     6: 00000000     0 FUNC    GLOBAL DEFAULT    1 __divdi3@GLIBC_2.0

(Yes, a versioned symbol really is just a regular symbol table entry
with @WHATEVER tacked on the end of its name, at least in an .o file.
I checked.)

The only differences (ignoring the actual contents of the text
section) I can find between this object file and the one we currently
get from shlib-compat.h are that this file doesn't have an unsuffixed
definition of __divdi3 (which is fine, because the version script
would strip it anyway) and the new __divdi3@GLIBC_2.0 symbol doesn't
have a size annotation (which I *think* is harmless).

But before I do a lot of painful mucking around in the Makefiles to
make this happen, I'd like to ask whether there's any reason this
won't work.  I used to know ELF inside and out, but that was a long
time ago and there's a lot I've forgotten.

zw