From patchwork Tue Jul 1 13:28:04 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 1835 Received: (qmail 5379 invoked by alias); 1 Jul 2014 13:28:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 5345 invoked by uid 89); 1 Jul 2014 13:28:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Tue, 1 Jul 2014 14:28:04 +0100 From: "Maciej W. Rozycki" To: CC: "Joseph S. Myers" Subject: [PATCH][BZ #17078] ARM: R_ARM_TLS_DESC prelinker support Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Hello, Here 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). The change below only handle the first case. In this scenario the prelinker does what the dynamic linker would do, that is preinitialises R_ARM_TLS_DESC relocations with a pointer to the lazy specialisation 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 specialisation 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 specialisation is unavailable and the DT_TLSDESC_PLT dynamic tag is not present. The prelinker could assume the common case of static specialisation and resolve the relocation, but that would require the exposure of dynamic linker's specialisation worker function. Furthermore the dynamic linker would have to handle the relocation in the conflict resoultion path and see if the dynamic specialisation shouldn't be used instead. This however would require access to data structures currently not made available to the conflict resoultion 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. The changes below resolve 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 unless someone has an idea how to do that, this fix will have to rely on using the prelinker test suite and enabling TLS descriptors there for coverage. This has been verified across a number of multilibs with no regressions in our test suite. OK to apply? 2014-07-01 Maciej W. Rozycki [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. Maciej glibc-arm-tlsdesc-prelink.patch Index: glibc-fsf-trunk-quilt/sysdeps/arm/dl-machine.h =================================================================== --- glibc-fsf-trunk-quilt.orig/sysdeps/arm/dl-machine.h 2014-06-23 03:36:48.621961686 +0100 +++ glibc-fsf-trunk-quilt/sysdeps/arm/dl-machine.h 2014-06-23 03:37:04.621789475 +0100 @@ -573,6 +573,32 @@ elf_machine_rela (struct link_map *map, case R_ARM_ABS32: *reloc_addr = value + reloc->r_addend; break; +# ifdef RESOLVE_CONFLICT_FIND_MAP + case R_ARM_TLS_DESC: + { + struct tlsdesc volatile *td = + (struct tlsdesc volatile *) reloc_addr; + + RESOLVE_CONFLICT_FIND_MAP (map, reloc_addr); + + /* Make sure we know what's going on. */ + assert (td->entry + == (void *) (D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) + + map->l_addr)); + assert (map->l_info[ADDRIDX (DT_TLSDESC_GOT)]); + + /* Set up the lazy resolver and store the pointer to our link + map in _GLOBAL_OFFSET_TABLE[1] now as for a prelinked + binary elf_machine_runtime_setup() is not called and hence + neither has been initialized. */ + *(Elf32_Addr *) (D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + + map->l_addr) + = (Elf32_Addr) &_dl_tlsdesc_lazy_resolver; + ((Elf32_Addr *) D_PTR (map, l_info[DT_PLTGOT]))[1] + = (Elf32_Addr) map; + } + break; +# endif /* RESOLVE_CONFLICT_FIND_MAP */ case R_ARM_PC24: relocate_pc24 (map, value, reloc_addr, reloc->r_addend); break; @@ -652,9 +678,11 @@ elf_machine_lazy_rel (struct link_map *m (struct tlsdesc volatile *)reloc_addr; /* The linker must have given us the parameter we need in the - first GOT entry, and left the second one empty. We fill the - last with the resolver address */ - assert (td->entry == 0); + first GOT entry, and left the second one empty. The latter + will have been preset by the prelinker if used though. + We fill it with the resolver address. */ + assert (td->entry == 0 + || map->l_info[VALIDX (DT_GNU_PRELINKED)] != NULL); td->entry = (void*)(D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_PLT)]) + map->l_addr); }