* Pulling libgcc compat symbols out of libgcc.a
@ 2017-05-24 18:26 Zack Weinberg
2017-05-26 19:48 ` Adhemerval Zanella
0 siblings, 1 reply; 2+ messages in thread
From: Zack Weinberg @ 2017-05-24 18:26 UTC (permalink / raw)
To: GNU C Library
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Pulling libgcc compat symbols out of libgcc.a
2017-05-24 18:26 Pulling libgcc compat symbols out of libgcc.a Zack Weinberg
@ 2017-05-26 19:48 ` Adhemerval Zanella
0 siblings, 0 replies; 2+ messages in thread
From: Adhemerval Zanella @ 2017-05-26 19:48 UTC (permalink / raw)
To: libc-alpha
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.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2017-05-26 19:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-24 18:26 Pulling libgcc compat symbols out of libgcc.a Zack Weinberg
2017-05-26 19:48 ` Adhemerval Zanella
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).