From patchwork Tue Nov 6 12:00:46 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Newbury X-Patchwork-Id: 30036 Received: (qmail 95356 invoked by alias); 6 Nov 2018 12:00:56 -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 95256 invoked by uid 89); 6 Nov 2018 12:00:51 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-12.9 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=googlemail.com, googlemailcom, H*F:D*googlemail.com, UD:googlemail.com X-HELO: mail-wr1-f54.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a1q32gQvIYPMbJknHPEDD1qKRjrqVI+KcaM/j/ePJyI=; b=LkMDiJBwilIOt1izTCLb6gvSkFETa7v1uZsnDjd/MZMryGq8GmOewBJgjtfc13o+ul V5z20R1t+6UZGACNzkB3CcSTOGAZqUpR+sP8l81K4J2QWeqmY9nd4g7MYkyI7VGeXoAY UOqKEhddxNGuK3VW9bjTPKIn7SiQZSFUvV3aUr3Qs1wmtncTZYZiPkBa2gs4cecGu7+p V2RwTo0NPjuddsqTC11kCx+im6EbJqWGYpgcUw/zywVIgxkZvMFwcoGZaujcCj6mR5yC sBsihp2M73+OvL+JXpVCSJEaifO8JnthRC7Q2QdSab+WMiVw5UAuaLVlrwe385UuH1Pg JIWw== MIME-Version: 1.0 In-Reply-To: References: From: Steven Newbury Date: Tue, 6 Nov 2018 12:00:46 +0000 Message-ID: Subject: Re: x86-64 prelink support for TLS dialect gnu2 To: Szabolcs Nagy Cc: "libc-alpha@sourceware.org" , nd On 06/11/2018, Steven Newbury wrote: > From the reverted ARM prelink patch it's clear the magic is in the > section guarded > by RESOLVE_CONFLICT_FIND_MAP. The x86_64 code already handles several > different cases of R_X86_64_TLSDESC in that switch so I still don't > understand how it falls through to _dl_reloc_bad_type rather than just > ignoring the prelink suppliied address. Most of the ARM patch > consists of asserts presumably because the code wasn't fully trusted. > Okay, I've applied the attached patch inserting the code removed from the ARM dl-machine.h into the x86_64 code handling R_X86_64_TLSDESC. I still get the same error: error while loading shared libraries: unexpected reloc type 0x24 Which can only be coming from _dl_reloc_bad_type() after it's fallen through the switch in elf_machine_rela() or the if-else block in elf_machine_lazy_rel(), both of which have should not fall through since R_X86_64_TLSDESC is reloc type 0x24 and it is, or should be handled! --- ./sysdeps/x86_64/dl-machine.h.orig 2018-11-06 09:51:14.316220266 +0000 +++ ./sysdeps/x86_64/dl-machine.h 2018-11-06 09:53:17.511458780 +0000 @@ -392,6 +392,29 @@ struct tlsdesc volatile *td = (struct tlsdesc volatile *)reloc_addr; +# ifdef RESOLVE_CONFLICT_FIND_MAP + if (map->l_info[VALIDX (DT_GNU_PRELINKED)] != NULL) + { + 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. */ + *(ElfW(Addr) *) (D_PTR (map, l_info[ADDRIDX (DT_TLSDESC_GOT)]) + + map->l_addr) + = (ElfW(Addr)) &_dl_tlsdesc_lazy_resolver; + ((ElfW(Addr) *) D_PTR (map, l_info[DT_PLTGOT]))[1] + = (ElfW(Addr)) map; + } + else +# endif # ifndef RTLD_BOOTSTRAP if (! sym) {