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 7D437740041 for ; Fri, 27 Oct 2023 14:43:20 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=B7Kjap/FUrInZhAcwDsEMwjouNM/zpSgqaBZ0DrSoCA=; 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=1698417799; v=1; b=K8VD6F2N8m35DzQ06bDBak/DVoDYKX5QIYdDwAtBun9Wae+RA+W6QU00/XJFAHJA7c2P0ILX Ik1XeGFBrDoKcomxH4Ie1T97v0qsO24fOiqIBIuttybPuuaIQW3+ens7w0PSTYwh27Dbqvc/mAH MCoVL2djJWdogKi9L7TCV4Og= X-Received: by 127.0.0.2 with SMTP id BTNsYY7687511xDdaFEDxz2q; Fri, 27 Oct 2023 07:43:19 -0700 X-Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mx.groups.io with SMTP id smtpd.web10.8659.1698417798153930220 for ; Fri, 27 Oct 2023 07:43:18 -0700 X-Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 9FAE5CE44A1 for ; Fri, 27 Oct 2023 14:43:14 +0000 (UTC) X-Received: by smtp.kernel.org (Postfix) with ESMTPSA id D7DC7C433C9 for ; Fri, 27 Oct 2023 14:43:13 +0000 (UTC) X-Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2c3e23a818bso24118501fa.0 for ; Fri, 27 Oct 2023 07:43:13 -0700 (PDT) X-Gm-Message-State: tTf23oPmdsFm1OYbgQiYWS9Ix7686176AA= X-Google-Smtp-Source: AGHT+IE4I7EyeuXT2IqoWOjhnAJg1YbDd98L6k8FTtU4RSfKf2dRWMCkPkhQI+BR0CJO/lgvM8gBk90GJswli8d8lks= X-Received: by 2002:a2e:8698:0:b0:2c4:fe28:7b45 with SMTP id l24-20020a2e8698000000b002c4fe287b45mr2471395lji.8.1698417792044; Fri, 27 Oct 2023 07:43:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Ard Biesheuvel" Date: Fri, 27 Oct 2023 16:43:00 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP To: Pedro Falcato Cc: devel@edk2.groups.io, jake@nvidia.com, "rebecca@bsdio.com" , "gaoliming@byosoft.com.cn" , "bob.c.feng@intel.com" , "yuwei.chen@intel.com" 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,ardb@kernel.org 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=K8VD6F2N; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=kernel.org (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, 27 Oct 2023 at 16:26, Pedro Falcato wrote= : > > On Fri, Oct 27, 2023 at 3:13=E2=80=AFPM Ard Biesheuvel = wrote: > > > > On Fri, 27 Oct 2023 at 16:09, Jake Garver via groups.io > > wrote: > > > > > > Hi Ard: > > > > > > > Can you double check the object file? I suspect this is a linker re= laxation not a compiler issue. > > > > > > With LTO in play, is there a way to check the object file? It's not = in aarch64 assembly. > > > > > > > Perhaps not. > > > > Could you try adding -Wl,--no-relax to the DLINK_FLAGS for your build > > and see if it makes a difference? > > > > We should be adding that in any case, but it would be good to know if > > it helps here too. > > I've never checked on aarch64, but don't you get solid space savings > with linker relaxation? Or is it mostly meaningless? > The most important use case for linker relaxation is turning GOT lookups into relative references, given that PIC object files are typically constructed without prior knowledge of whether a given external reference will be satisfied by the same dynamic object or a different one. So each relaxation removes a load from the program and may reduce the size of the GOT (if no other non-relaxable references to it exist) and this might matter on a hot path. None of this makes sense for UEFI, though, given that all executables are fully linked and performance doesn't usually matter to the same extent. On AArch64, there is a specific advantage to being able to relax ADRP to ADR (and this is why GenFw implements this relaxation itself too): ADRP instructions need to appear at the same offset modulo 4k as they were linked at, which means 4k alignment for the entire code section. EDK2 builds are made up of lots of tiny SEC and PEI drivers and rounding up each of those to 4k would result in a substantial increase in footprint of the firmware image. -=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 (#110214): https://edk2.groups.io/g/devel/message/110214 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-