From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17393 invoked by alias); 17 Jul 2014 18:46:54 -0000 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org Received: (qmail 17079 invoked by uid 55); 17 Jul 2014 18:46:47 -0000 From: "cvs-commit at gcc dot gnu.org" To: glibc-bugs@sourceware.org Subject: [Bug dynamic-link/17078] error while loading shared libraries: unexpected reloc type 0x0d Date: Thu, 17 Jul 2014 18:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: dynamic-link X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: security- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-07/txt/msg00634.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=17078 --- Comment #1 from 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 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.