This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/17485] New: [2.20 regression] MIPS: ld: libpthread.so: invalid string offset 2765592330 >= 5154 for section `.dynstr'
- From: "macro at linux-mips dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Tue, 14 Oct 2014 21:03:05 +0000
- Subject: [Bug libc/17485] New: [2.20 regression] MIPS: ld: libpthread.so: invalid string offset 2765592330 >= 5154 for section `.dynstr'
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=17485
Bug ID: 17485
Summary: [2.20 regression] MIPS: ld: libpthread.so: invalid
string offset 2765592330 >= 5154 for section `.dynstr'
Product: glibc
Version: 2.20
Status: NEW
Severity: critical
Priority: P1
Component: libc
Assignee: macro@linux-mips.org
Reporter: macro@linux-mips.org
CC: drepper.fsp at gmail dot com
Target: mips-linux-gnu
This change:
commit 58eb0862c3471b931bf3412d6d02bac447d5a653
Author: Roland McGrath <roland@hack.frob.com>
Date: Fri Jun 27 09:58:51 2014 -0700
MIPS: Consolidate NPTL/non versions of vfork
regressed MIPS builds of librt.so, depending on how the BFD linker
internals work out, which generally depends on multilib options, either
an empty entry is left in the dynamic symbol table or a build failure
is triggered like this:
.../mips-linux-gnu/bin/ld: .../nptl/libpthread.so: invalid string offset
2765592330 >= 5154 for section `.dynstr'
.../nptl/libpthread.so: could not read symbols: File format not recognized
collect2: error: ld returned 1 exit status
This is a bug in GNU LD and also GAS, but I think we have a bug too, in
the MIPS version of pt-vfork.S, that triggers this obscure corner case.
Before the change it assembled to have a symbol table like this:
Symbol table '.symtab' contains 20 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 3
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000001 0 NOTYPE LOCAL DEFAULT ABS LOCALSZ
5: 00000018 0 NOTYPE LOCAL DEFAULT ABS FRAMESZ
6: 00000014 0 NOTYPE LOCAL DEFAULT ABS GPOFF
7: 00000000 0 SECTION LOCAL DEFAULT 11
8: 00000000 0 SECTION LOCAL DEFAULT 13
9: 00000000 0 SECTION LOCAL DEFAULT 9
10: 00000000 0 SECTION LOCAL DEFAULT 14
11: 00000000 0 SECTION LOCAL DEFAULT 16
12: 00000000 0 SECTION LOCAL DEFAULT 5
13: 00000000 0 SECTION LOCAL DEFAULT 6
14: 00000000 0 SECTION LOCAL DEFAULT 7
15: 00000000 0 SECTION LOCAL DEFAULT 18
16: 00000000 112 FUNC GLOBAL DEFAULT 1 __vfork
17: 00000000 0 OBJECT GLOBAL DEFAULT UND _gp_disp
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND __syscall_error
19: 00000000 112 FUNC WEAK DEFAULT 1 vfork
With the change in place the symbol table is like this instead:
Symbol table '.symtab' contains 21 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 3
3: 00000000 0 SECTION LOCAL DEFAULT 4
4: 00000001 0 NOTYPE LOCAL DEFAULT ABS LOCALSZ
5: 00000018 0 NOTYPE LOCAL DEFAULT ABS FRAMESZ
6: 00000014 0 NOTYPE LOCAL DEFAULT ABS GPOFF
7: 00000000 0 SECTION LOCAL DEFAULT 11
8: 00000000 0 SECTION LOCAL DEFAULT 13
9: 00000000 0 SECTION LOCAL DEFAULT 9
10: 00000000 0 SECTION LOCAL DEFAULT 14
11: 00000000 0 SECTION LOCAL DEFAULT 16
12: 00000000 0 SECTION LOCAL DEFAULT 5
13: 00000000 0 SECTION LOCAL DEFAULT 6
14: 00000000 0 SECTION LOCAL DEFAULT 7
15: 00000000 0 SECTION LOCAL DEFAULT 18
16: 00000000 140 FUNC GLOBAL DEFAULT 1 __vfork
17: 00000000 0 OBJECT GLOBAL DEFAULT UND _gp_disp
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND __syscall_error
19: 00000000 140 FUNC WEAK DEFAULT 1 vfork
20: 00000000 0 NOTYPE GLOBAL DEFAULT UND vfork@GLIBC_2.0
-- notice the undefined versioned entry for `vfork@GLIBC_2.0'. This is
what confuses LD and also shouldn't have been produced by GAS in the
first place.
There's no further reference to that symbol, i.e. no relocation
anywhere across this object file, which is why LD removes it from
libpthread.so's dynsym table, however it doesn't realise early enough
it shouldn't be propagating the reference to the dynsym table in the
first place and as a result it leaves an uninitialised slot that may or
may not be empty.
The ultimate reason for this symbol's creation is a:
.symver __libc_vfork, vfork@GLIBC_2.0
directive however without any `__libc_vfork' definition or reference.
This is what the GAS manual has to say about this case:
" For ELF targets, the `.symver' directive can be used like this:
.symver NAME, NAME2@NODENAME
" If the symbol NAME is not defined within the file being assembled,
all references to NAME will be changed to NAME2@NODENAME. If no
reference to NAME is made, NAME2@NODENAME will be removed from the
symbol table."
so the symbol is supposed not to be emitted. It appears though that
this bug has been present in GNU binutils since forever and our other
targets define `__libc_vfork', possibly just as an alias to `__vfork',
so I think we should simply do the same for MIPS. The symbol does not
make it to the dynsym table so such a change will not affect our ABI.
--
You are receiving this mail because:
You are on the CC list for the bug.