From patchwork Wed Apr 30 15:25:20 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Brown X-Patchwork-Id: 344189 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org 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 88A0214009C for ; Thu, 1 May 2014 01:25:45 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id :mime-version:content-type; q=dns; s=default; b=GRPkdzbYnfO4PxRM kWg3xnjmd+nyXG7/DvKnhtdrwXhbCBwZwxlUa0yQ8LWvkZeVBapjVGeifAYEEIyR l6Xktgtg0lbXhm75aamZKVnU9vdZ5CyEsMBrOSlkNor6q1EpMEUquS0kO1TEhLhz kmttvhT4MM/gPnq+00KHqY+uz5g= 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:date:from:to:cc:subject:message-id :mime-version:content-type; s=default; bh=RoEQubFGFqZdsQFALpHrDp QGicQ=; b=WPDWGEgLoqOnzrmFyT+ZaWuw89d+TJ6X+Fjhb6Do3WpPyxLnT7YsTy SsqGdkiK2GJEN8531whJV25RRjxN/Er+hmAWDq/odXSnk+FJb0oXGr0i8vuUV1jh iKiZeIAohXObtKfxEwrKsKWowuAXuqMtaovuuoy3shexvwmCp+I6o= Received: (qmail 3811 invoked by alias); 30 Apr 2014 15:25:39 -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 3802 invoked by uid 89); 30 Apr 2014 15:25:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Wed, 30 Apr 2014 16:25:20 +0100 From: Julian Brown To: CC: Jakub Jelinek , Subject: [PATCH] ARM: Fix R_ARM_IRELATIVE RELA relocations Message-ID: <20140430162520.7d7eb209@octopus> MIME-Version: 1.0 Hi, This patch fixes what I believe to be a bug in the handling of R_ARM_IRELATIVE RELA relocations. At present, these are handled the same as REL relocations: i.e. the addend is loaded from the relocation address. Most of the time this isn't a problem because RELA relocations aren't used on ARM (GNU/Linux at least) anyway, but it causes problems with prelink, which uses RELA on all targets for its conflict table. (Support for ifunc prelinking requires a prelink patch, not yet posted.) Anyway, this patch works, though I'm not 100% sure if it is correct: I notice that this code path received attention last year: https://sourceware.org/ml/libc-ports/2013-07/msg00000.html I'm not sure under what circumstances that patch would have had an effect, nor if my patch conflicts with that case. No regressions using Mentor's usual glibc cross-testing infrastructure. OK to apply? (Strangely, this appears to be my first glibc patch, so I'm not entirely certain if I have write access!) Thanks, Julian ChangeLog * sysdeps/arm/dl-machine.h (elf_machine_rela): Fix R_ARM_IRELATIVE handling. diff --git a/sysdeps/arm/dl-machine.h b/sysdeps/arm/dl-machine.h index 02d1a5e..899b256 100644 --- a/sysdeps/arm/dl-machine.h +++ b/sysdeps/arm/dl-machine.h @@ -594,7 +594,7 @@ elf_machine_rela (struct link_map *map, const Elf32_Rela *reloc, } break; case R_ARM_IRELATIVE: - value = map->l_addr + *reloc_addr; + value = map->l_addr + reloc->r_addend; value = ((Elf32_Addr (*) (int)) value) (GLRO(dl_hwcap)); *reloc_addr = value; break;