Re: Pulling libgcc compat symbols out of libgcc.a

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 24/05/2017 15:26, Zack Weinberg wrote:
> 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.

I can't really tell if it won't work, but I am not very found of this
approach for some reasons:

* It does not guarantee to solve any problem described in your 
  description.  If the architecture backends still emits about for
  __buitin_trap it will continue potentially pull abort where it
  should not.  For second problem, it can potentially be fixed by
  pulling libgcc.a implementation, but we can also just keep both
  in sync.  These are usually stable implementation that do not
  change over time, so keep them in sync is not usually a burden.

* Maybe glibc will never support other build compiler than gnu ones,
  but I would like to avoid add more tooling specific features and
  simplify general building.  I know we already have specific binutils
  version as pre-requisite, but for this specific case I see no
  straightforward gain of adding another external tool support as
  build pre-requisite.