From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 8BA52740046 for ; Fri, 27 Oct 2023 14:10:16 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Ie7AdMFNS4zh6DeT8yZGzzmnozd9CZXw9XGxguMVifk=; c=relaxed/simple; d=groups.io; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698415815; v=1; b=okeIO+7JaEwhtGbmk6IsnK7n6MTI5Ynl8b54AeOT6ySg0vLezXlU8/M+7h8tuWwbt4Z0rgLW wfcQnf6HxKp3ZGvR/6sLzNMXBm5bAJVBQYwrGZk74Ttp7zZA1jbjE/f8iH/tsA64DEnXkW+Kfuc rzKYQeDX9zxHzSQ9ix0sJB3A= X-Received: by 127.0.0.2 with SMTP id DDPsYY7687511x6WGwChMJ05; Fri, 27 Oct 2023 07:10:15 -0700 X-Received: from mail-vs1-f41.google.com (mail-vs1-f41.google.com [209.85.217.41]) by mx.groups.io with SMTP id smtpd.web10.7928.1698415814546896302 for ; Fri, 27 Oct 2023 07:10:14 -0700 X-Received: by mail-vs1-f41.google.com with SMTP id ada2fe7eead31-457e36dcab6so2094459137.0 for ; Fri, 27 Oct 2023 07:10:14 -0700 (PDT) X-Gm-Message-State: chUqIqcxgzGC9PQPjUrK2Wvox7686176AA= X-Google-Smtp-Source: AGHT+IFn/p3+MXrUL2k0ZtSvQ6M+Fcwh+f6D/s5DuFdjzHsfc2VizP8Taup+wJAjoT10zYNU1aDf8H3wXgioLC4Pie4= X-Received: by 2002:a1f:ee87:0:b0:48d:5be:2868 with SMTP id m129-20020a1fee87000000b0048d05be2868mr1963701vkh.0.1698415813370; Fri, 27 Oct 2023 07:10:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Pedro Falcato" Date: Fri, 27 Oct 2023 15:10:01 +0100 Message-ID: Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP To: Ard Biesheuvel Cc: devel@edk2.groups.io, jake@nvidia.com, "rebecca@bsdio.com" , "gaoliming@byosoft.com.cn" , "bob.c.feng@intel.com" , "yuwei.chen@intel.com" , "ardb+tianocore@kernel.org" Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,pedro.falcato@gmail.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=okeIO+7J; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Fri, Oct 27, 2023 at 2:47=E2=80=AFPM Ard Biesheuvel wr= ote: > > Hello all, > > Apologies for the late response. > > On Fri, 27 Oct 2023 at 14:44, Jake Garver via groups.io > wrote: > > > > Thanks for your response, Pedro. > > > > I chased this as a toolchain bug originally, but concluded that the ADR= indeed works before GenFw rewrites it. But I see your point regarding the= relocation statement. > > > > As requested, below is the disassembled function along with relocations= . This was generated from the dll using "aarch64-linux-gnu-objdump -r -D".= The ADR in question is at 2ffc. > > > > Can you double check the object file? I suspect this is a linker > relaxation not a compiler issue. > > > This code was generated by the current version of the GCC 10.x toolchai= n on Ubuntu20. So, if we're concluding this is a toolchain issue, then it'= s with a fairly "stock" toolchain. > > > > 0000000000002fec : > > 2fec:=E2=80=82=E2=80=82=E2=80=82a9b97bfd stp=E2=80=82=E2=80=82=E2= =80=82x29, x30, [sp, #-112]! > > 2ff0:=E2=80=82=E2=80=82=E2=80=82910003fd mov=E2=80=82=E2=80=82=E2= =80=82x29, sp > > 2ff4:=E2=80=82=E2=80=82=E2=80=82a90363f7 stp=E2=80=82=E2=80=82=E2= =80=82x23, x24, [sp, #48] > > 2ff8:=E2=80=82=E2=80=82=E2=80=82aa0003f8 mov=E2=80=82=E2=80=82=E2= =80=82x24, x0 > > 2ffc:=E2=80=82=E2=80=82=E2=80=8210020020 adr=E2=80=82=E2=80=82=E2= =80=82x0, 7000 <_cont+0xe98> > > 2ffc: R_AARCH64_ADR_GOT_PAGE=E2=80=82=E2=80=82__stack_chk_guard > > The nasty thing with relying on --emit-relocs is that they get out of > sync. R_AARCH64_ADR_GOT_PAGE is documented as applying to ADRP only, > so this code is non-compliant one way or the other. I was narrowing it down to this, but _ADR_GOT_PAGE does not seem to be relaxable as ADRP -> ADR, per the ABI spec (see "Large GOT Indirection". "PC-relative addressing" only applies to _ADR_PREL_PG_HI21...) Maybe it's just not a documented relaxation? Or does it relax as _ADR_GOT_PAGE -> _ADR_PREL_PG_HI21 -> _ADR_PREL_LO21 without updating internal relocation info? > > There are other relaxations that also confuse GenFw when the static > relocs don't get updated accordingly. Wonderful that you can confirm this is probably a linker --emit-relocs issue. So, if this proves to be the case: Acked-by: Pedro Falcato but please rewrite the commit message so that it's clear that this is an --emit-relocs toolchain bug. --=20 Pedro -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110209): https://edk2.groups.io/g/devel/message/110209 Mute This Topic: https://groups.io/mt/102202314/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-