public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug dynamic-link/17078] New: error while loading shared libraries: unexpected reloc type 0x0d
@ 2014-06-23 2:18 macro@linux-mips.org
2014-06-23 8:21 ` [Bug dynamic-link/17078] " fweimer at redhat dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: macro@linux-mips.org @ 2014-06-23 2:18 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17078
Bug ID: 17078
Summary: error while loading shared libraries: unexpected reloc
type 0x0d
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
Assignee: unassigned at sourceware dot org
Reporter: macro@linux-mips.org
CC: macro@linux-mips.org
Target: arm-linux-gnueabi
All the TLS test cases fail in the prelinker test suite when built with
the use of R_ARM_TLS_DESC relocations, that is with the
`-mtls-dialect=gnu2' GCC option in effect. The following messages are
produced:
./tls1: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls1.sh
./tls2: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls2.sh
./tls3: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls3.sh
./tls4: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls4.sh
./tls5: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls5.sh
./tls6: error while loading shared libraries: unexpected reloc type 0x0d
FAIL: tls6.sh
The reason is the lack of handling for prelinked R_ARM_TLS_DESC
relocations in the dynamic linker.
Borrowing the testcase from bug #17075 it can also be reproduced as
follows:
$ cat libgetfoo.c
int __thread foo;
int
getfoo (void)
{
return foo;
}
$ arm-linux-gnueabi-gcc -mtls-dialect=gnu2 -fPIC -shared
-Wl,-dynamic-linker,.../lib/ld-linux.so.3 -Wl,-rpath,.../lib -Wl,-rpath,$(pwd)
-o libgetfoo.so libgetfoo.c
$ cat getfoo.c
int getfoo (void);
int
main (void)
{
return getfoo ();
}
$ arm-linux-gnueabi-gcc -mtls-dialect=gnu2
-Wl,-dynamic-linker,.../lib/ld-linux.so.3 -Wl,-rpath,.../lib -Wl,-rpath,$(pwd)
-o getfoo -L. -lgetfoo getfoo.c
$ ssh arm-host $(pwd)/getfoo
$ echo $?
0
$ echo .../lib > prelink.conf
$ echo $(pwd) >> prelink.conf
$ arm-linux-gnueabi-prelink -c ./prelink.conf -C ./prelink.cache
--ld-library-path=.../lib:$(pwd) --dynamic-linker=.../lib/ld-linux.so.3 -v
getfoo
Laying out 4 libraries in virtual address space 41000000-50000000
Assigned virtual address space slots for libraries:
.../lib/ld-linux.so.3 41000000-41028954
.../lib/libc.so.6 41030000-4116d588
.../lib/libgcc_s.so.1 41170000-4119832c
$(pwd)/libgetfoo.so 411a0000-411a8910
Prelinking .../lib/ld-2.19.90.so
Prelinking .../lib/libc-2.19.90.so
Prelinking .../lib/libgcc_s.so.1
Prelinking $(pwd)/libgetfoo.so
Prelinking $(pwd)/getfoo
$ ssh arm-host $(pwd)/getfoo
$(pwd)/getfoo: error while loading shared libraries: unexpected reloc type 0x0d
$ echo $?
127
$
I have substituted `...' for the sysroot path and $(pwd) for the CWD even
in output to avoid clutter.
The ARM TLS descriptor specification can be referred at bug #17075.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug dynamic-link/17078] error while loading shared libraries: unexpected reloc type 0x0d
2014-06-23 2:18 [Bug dynamic-link/17078] New: error while loading shared libraries: unexpected reloc type 0x0d macro@linux-mips.org
@ 2014-06-23 8:21 ` fweimer at redhat dot com
2014-07-17 18:46 ` cvs-commit at gcc dot gnu.org
2014-07-17 18:49 ` macro@linux-mips.org
2 siblings, 0 replies; 4+ messages in thread
From: fweimer at redhat dot com @ 2014-06-23 8:21 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17078
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug dynamic-link/17078] error while loading shared libraries: unexpected reloc type 0x0d
2014-06-23 2:18 [Bug dynamic-link/17078] New: error while loading shared libraries: unexpected reloc type 0x0d macro@linux-mips.org
2014-06-23 8:21 ` [Bug dynamic-link/17078] " fweimer at redhat dot com
@ 2014-07-17 18:46 ` cvs-commit at gcc dot gnu.org
2014-07-17 18:49 ` macro@linux-mips.org
2 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2014-07-17 18:46 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17078
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via 9c82da17b5794efebe005de2fd22d61a3ea4b58a (commit)
from 831b9896d8e957580591a3cbe11dcd5ac6743ba2 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=9c82da17b5794efebe005de2fd22d61a3ea4b58a
commit 9c82da17b5794efebe005de2fd22d61a3ea4b58a
Author: Maciej W. Rozycki <macro@codesourcery.com>
Date: Thu Jul 17 19:22:05 2014 +0100
[BZ #17078] ARM: R_ARM_TLS_DESC prelinker support
This is a change to the dynamic linker to add prelinker support for the
R_ARM_TLS_DESC relocation. Two cases can be considered here, the usual
one where lazy binding is in use and the less frequent one, where
immediate binding is requested via the use of the DF_BIND_NOW dynamic
flag (e.g. by using the GNU linker's "-z now" option).
This change only handles the first case. In this scenario the prelinker
does what the dynamic linker would do, that is it preinitialises
R_ARM_TLS_DESC relocations with a pointer to the lazy specialization as
provided with the DT_TLSDESC_PLT dynamic tag. A conflict is
additionally created and in the conflict resolution path the dynamic
linker complements the work by initialising the object's pointer as
indicated by the DT_TLSDESC_GOT dynamic tag to the linker's internal
lazy specialization worker function and also providing the associated
link map in the second entry of the GOT. This step is required, because
if prelinking is successful at the run time, then the dynamic linker's
elf_machine_runtime_setup() function isn't called that would normally do
so.
The second case remains unresolved, because support for that scenario
has not been implemented in the prelinker. In this case the lazy
specialization is unavailable and the DT_TLSDESC_PLT dynamic tag is not
present.
The prelinker could assume the common case of static specialization and
resolve the relocation, but that would require the exposure of dynamic
linker's specialization worker function. Furthermore the dynamic linker
would have to handle the relocation in the conflict resolution path and
see if the dynamic specialization should be used instead. This however
would require access to data structures currently not made available to
the conflict resolution path and therefore a redesign of this part of
the dynamic linker.
Alternatively the prelinker could defer all processing to the dynamic
linker's conflict resolution path, but that would require similar access
to the said data structures.
Therefore the prelinker issues an error instead and the dynamic linker
has assertions to check that DT_TLSDESC_PLT and DT_TLSDESC_GOT are in
use in its conflict resolution path.
This change resolves all TLS failures in the prelinker testsuite, as
noted in the bug report, as well as the small test case provided there.
Unfortunately we don't seem to have any hooks to factor in the prelinker
(if present on a system) to testing, so at this time this fix has to
rely on using the prelinker test suite and enabling TLS descriptors
there for coverage.
[BZ #17078]
* sysdeps/arm/dl-machine.h (elf_machine_rela)
[RESOLVE_CONFLICT_FIND_MAP]: Handle R_ARM_TLS_DESC relocation.
(elf_machine_lazy_rel): Handle prelinked R_ARM_TLS_DESC entries.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 7 +++++++
NEWS | 4 ++--
sysdeps/arm/dl-machine.h | 34 +++++++++++++++++++++++++++++++---
3 files changed, 40 insertions(+), 5 deletions(-)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug dynamic-link/17078] error while loading shared libraries: unexpected reloc type 0x0d
2014-06-23 2:18 [Bug dynamic-link/17078] New: error while loading shared libraries: unexpected reloc type 0x0d macro@linux-mips.org
2014-06-23 8:21 ` [Bug dynamic-link/17078] " fweimer at redhat dot com
2014-07-17 18:46 ` cvs-commit at gcc dot gnu.org
@ 2014-07-17 18:49 ` macro@linux-mips.org
2 siblings, 0 replies; 4+ messages in thread
From: macro@linux-mips.org @ 2014-07-17 18:49 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=17078
Maciej W. Rozycki <macro@linux-mips.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #2 from Maciej W. Rozycki <macro@linux-mips.org> ---
Fixed as per the automatically entered commit message.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-07-17 18:49 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-23 2:18 [Bug dynamic-link/17078] New: error while loading shared libraries: unexpected reloc type 0x0d macro@linux-mips.org
2014-06-23 8:21 ` [Bug dynamic-link/17078] " fweimer at redhat dot com
2014-07-17 18:46 ` cvs-commit at gcc dot gnu.org
2014-07-17 18:49 ` macro@linux-mips.org
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).