From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28474 invoked by alias); 26 Jun 2013 15:36:17 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 28446 invoked by uid 89); 26 Jun 2013 15:36:12 -0000 X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1 Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com) (209.85.220.54) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 26 Jun 2013 15:36:11 +0000 Received: by mail-pa0-f54.google.com with SMTP id kx10so14345727pab.27 for ; Wed, 26 Jun 2013 08:36:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=X664+YPulAPZ2CLZ4YsvzbVoyiXuM57sRGtK9/jaJRk=; b=YgznbWuudX5lgaMR6H/5fR3iiXJrxLMNPwJc5TBdDOYDyfgl/ZJROru2nblziTG4YT oIk4JpdLkJan7SXS3hKF62iQel+KPhWJDp3ZCNU6wAiEPsPvP9K2vH6T0MzIh9mHDv6u ACpIjiXK1M5ZoqEfarQrnzeskdYc/nzk88/XR7DWyKu0p68WMUMGOCYr5TShV49YSRhm y2RRd4rdtjRLJuKQvgFbBQzJWU/FBert7cZc4B0m4ARD+e6kfPDvmb7YdK1CuCSy8Rzl +IFJuFiJ1R1fUUc5eTgTHJrFl4FykIuRlTw6T7zc/CoWq8caWrAWtjZCbc8mFXSX4Asm 0qqA== MIME-Version: 1.0 X-Received: by 10.66.48.201 with SMTP id o9mr1302673pan.76.1372260970502; Wed, 26 Jun 2013 08:36:10 -0700 (PDT) Received: by 10.68.209.132 with HTTP; Wed, 26 Jun 2013 08:36:10 -0700 (PDT) In-Reply-To: <1372250579.3739.42.camel@t520.redhat.com> References: <1372092109.3739.13.camel@t520.redhat.com> <51C87F49.3070008@twiddle.net> <1372250579.3739.42.camel@t520.redhat.com> Date: Wed, 26 Jun 2013 15:36:00 -0000 Message-ID: Subject: Re: aarch64 prelink issue From: Marcus Shawcroft To: Mark Salter Cc: Richard Henderson , libc-ports Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmIKcboKtaPFX++wqvBjlsygbZi0sobnFHaA6uCIM5APK4ZiyBKjd4oaVfm68eaXUf351Wp X-SW-Source: 2013-06/txt/msg00057.txt.bz2 On 26 June 2013 13:42, Mark Salter wrote: > On Mon, 2013-06-24 at 10:18 -0700, Richard Henderson wrote: >> Try the x86_64 solution: >> >> /* This produces an IP-relative reloc which is resolved at link time. */ >> extern const ElfW(Addr) _GLOBAL_OFFSET_TABLE_[] attribute_hidden; >> return _GLOBAL_OFFSET_TABLE_[0]; >> >> with the extra hidden attribute, this should result in an ADR(P) >> reference to the _G_O_T_. >> > > This isn't working for aarch64. It doesn't use a PC-relative reference > and it tries reading from the GOT at the link time absolute address. It looks to me that Richard's proposal gives the correct sequence in elf_machine_dynamic(): adrp x0, _GLOBAL_OFFSET_TABLE_ ldr x0, [x0,#:lo12:_GLOBAL_OFFSET_TABLE_] ret ... but, this exposes an issue in the static linker: Currently the static linker produces: .got <-_GLOBAL_OFFSET_TABLE_ ... .gotplt[0] &_DYNAMIC <--DT_PLTGOT .gotplt[1] reserved for ld.so (&linkmap) .gotplt[2] reserved fpr ld.so (resolver) ... This layout is broken wrt the placement of &_DYNAMIC. The correct layout should be: .got[0] &_DYNAMIC <-_GLOBAL_OFFSET_TABLE_ ... .gotplt[0] reserved for ld.so (&linkmap) <--DT_PLTGOT .gotplt[1] reserved fpr ld.so (resolver) ... Hence when we use Richard's suggestion we end up picking junk out of .got[0] I'm still looking at this, but at the moment I think we can fix the static linker to emit: .got[0] &_DYNAMIC <-_GLOBAL_OFFSET_TABLE_ ... .gotplt[0] reserved for ld.so (&linkmap) <--DT_PLTGOT .gotplt[1] reserved for ld.so (resolver) .gotplt[2] reserved With this change, I believe that we do not introduce an incompatibility between existing binaries / .so's and the modified ld.so because the code within elf_machine_dynamic() is only instantiated within ld.so and is only used to inspect ld.so's own image. The .gotplt[2] entry remains reserved in the new layout to ensure that an unmodified ld.so can load a binary built using a modified static ld without clobbering the first real PLT entry. I'd really appreciate some feedback on the sanity of this proposal. Thanks /Marcus