From patchwork Mon Nov 5 16:21:44 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steven Newbury X-Patchwork-Id: 993209 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=sourceware.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=libc-alpha-return-96959-incoming=patchwork.ozlabs.org@sourceware.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=quarantine dis=none) header.from=googlemail.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.b="u2mdtaYL"; dkim=pass (2048-bit key; unprotected) header.d=googlemail.com header.i=@googlemail.com header.b="ULuLMz1K"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 42pdH455xTz9sDN for ; Tue, 6 Nov 2018 03:21:52 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:from:date:message-id:subject:to :content-type; q=dns; s=default; b=MJFbYUhO6ImO4De4hgsClhznT6Q86 MewAOoGp1yAgXPceK+4l57fqT2xb9Rscv8sHGcRpdIyaf11TorHPKQjriHQrGnhS R3UzoFR1ES1innTpSFowfGq3+Yf68qLvUKnbcLgrWZFFNlh4tnd+HqhAzNHtl2g7 p9xy3DdZrkcg54= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:from:date:message-id:subject:to :content-type; s=default; bh=CH9RJsUSZIDwO2di3ok10jUe8uc=; b=u2m dtaYLxU2CBgsty6BndDapCkueAV9kBh4iHAFIOelWhgY7vCwXmk/X4zO9oNqMcsf a9BexBKrXkFJkDIwYVdm1swauTIFGInRWjzWekElqDprs3Gy3iYwdhDMJ/YTnelt /y2Ktbi4aYwXIEwEoTNQetlVUDFBRful+DpVDDWo= Received: (qmail 19180 invoked by alias); 5 Nov 2018 16:21:47 -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 19170 invoked by uid 89); 5 Nov 2018 16:21:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.4 required=5.0 tests=BAYES_00, FREEMAIL_FROM, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy=HX-HELO:sk:mail-wr X-HELO: mail-wr1-f47.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=NXZSAUPShGYLI3moDBQtMeDiIBG5WFUwrQQLYF00YoE=; b=ULuLMz1K68Ro7EB8L64ohtkbSivaDTEDlsT0TwzlXcmSoP47NL4JLXJ+DW7qyg7ds6 30H5tbSvFH8HgDyA3mF+jm1J+OjaOiDahFfsG0vYkcWsoZPpEHSKdAY+KApruGvJBMo+ 24DMgTCd20R2c8BToCS+GIrG2dtmEl7SEhszsd4gYL4BQ/MSAM5iqevydM4oIWgbbHYY A4SQcwzloypqCreH06izXN+RqvAX2yCb9A9rAylH/aRglBsmkcTnBQSXlNzsvCGoMUbg 4qsO7x0WuXMgmwO6fKr0ECdDPD/1ymfvaJAsXcJX29Ah6P3FMZh9EKLy2jg5yg4MTUhk qbeQ== MIME-Version: 1.0 From: Steven Newbury Date: Mon, 5 Nov 2018 16:21:44 +0000 Message-ID: Subject: x86-64 prelink support for TLS dialect gnu2 To: libc-alpha@sourceware.org I'm working on gettting TLS gnu2 dialect support working for x86-64 with prelink. Yes, it's still maintained, see: https://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/ I've written the attached patch which enables prelink to recognise R_X86_64_TLSDESC relocations and do the same as is done currently for ARM. Unfortunately, while this seems to work, when a prelinked binary is loaded with a shared library with such a relocation it fails with: "error while loading shared libraries: unexpected reloc type 0x24". reloc type 0x24 is indeed R_X86_64_TLSDESC. The strange thing is the code in glibc which generates this error (sysdeps/x86_64/dl-machine.h) specifically handles R_X86_64_TLSDESC. I can't understand how it is falling through to _dl_reloc_bad_type () with reloc 0x24 since in both instances the error case shouldn't be reached! Can anybody help? From 963c95558ac1167121393d584bf00641a26eda4d Mon Sep 17 00:00:00 2001 From: Steven Newbury Date: Mon, 5 Nov 2018 09:29:05 +0000 Subject: [PATCH] Add support for R_X86_64_TLSDESC This is based on the R_ARM_TLS_DESC support code as integrated in commit 874b3d3f6413c16597ec92ed92c57d6bfe2bbb68 Signed-off-by: Steven Newbury --- src/arch-x86_64.c | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/src/arch-x86_64.c b/src/arch-x86_64.c index 2f6c551..9b1b7fb 100644 --- a/src/arch-x86_64.c +++ b/src/arch-x86_64.c @@ -133,6 +133,7 @@ x86_64_prelink_rela (struct prelink_info *info, GElf_Rela *rela, { DSO *dso; GElf_Addr value; + Elf64_Sword val; dso = info->dso; if (GELF_R_TYPE (rela->r_info) == R_X86_64_NONE @@ -184,6 +185,24 @@ x86_64_prelink_rela (struct prelink_info *info, GElf_Rela *rela, return 0; error (0, 0, "%s: R_X86_64_COPY reloc in shared library?", dso->filename); return 1; + case R_X86_64_TLSDESC: + if (!dso->info_DT_TLSDESC_PLT) + { + error (0, 0, + "%s: Unsupported R_X86_64_TLSDESC relocation in non-lazily bound object.", + dso->filename); + return 1; + } + val = read_ule64 (dso, rela->r_offset + 8); + if (val != 0 && !dynamic_info_is_set (dso, DT_GNU_PRELINKED_BIT)) + { + error (0, 0, + "%s: Unexpected non-zero value (0x%x) in R_X86_64_TLSDESC?", + dso->filename, val); + return 1; + } + write_le64 (dso, rela->r_offset + 8, dso->info_DT_TLSDESC_PLT); + break; default: error (0, 0, "%s: Unknown X86-64 relocation type %d", dso->filename, (int) GELF_R_TYPE (rela->r_info)); @@ -303,6 +322,9 @@ x86_64_prelink_conflict_rela (DSO *dso, struct prelink_info *info, /* Similarly IRELATIVE relocations always need conflicts. */ case R_X86_64_IRELATIVE: break; + /* Likewise TLSDESC. */ + case R_X86_64_TLSDESC: + break; default: return 0; } @@ -372,7 +394,9 @@ x86_64_prelink_conflict_rela (DSO *dso, struct prelink_info *info, break; } break; - + case R_X86_64_TLSDESC: + /* Nothing to do. */ + break; default: error (0, 0, "%s: Unknown X86-64 relocation type %d", dso->filename, (int) GELF_R_TYPE (rela->r_info)); @@ -498,6 +522,9 @@ x86_64_undo_prelink_rela (DSO *dso, GElf_Rela *rela, GElf_Addr relaaddr) case R_X86_64_TPOFF64: write_le64 (dso, rela->r_offset, 0); break; + case R_X86_64_TLSDESC: + write_le64 (dso, rela->r_offset + 8, 0); + break; case R_X86_64_32: case R_X86_64_PC32: write_le32 (dso, rela->r_offset, 0); @@ -556,6 +583,7 @@ x86_64_reloc_class (int reloc_type) case R_X86_64_DTPMOD64: case R_X86_64_DTPOFF64: case R_X86_64_TPOFF64: + case R_X86_64_TLSDESC: return RTYPE_CLASS_TLS; default: return RTYPE_CLASS_VALID; } -- 2.19.1