Ard, Pedro, How would you like to proceed here?
1. Do nothing. Treat it as a toolchain bug and not attempt a work-around. Practically speaking, this means the Ubuntu20 container at https://github.com/tianocore/containers cannot be updated to the latest GCC 10.x (10.5). We can pin it to 10.3 or EOL it, migrating to Ubuntu22. 2. Rework the patch as a work-around. 3. ??? Something I missed. Note in option 1, I'm assuming that other versions of GCC, e.g. 12.x used in Ubuntu22, don't eventually inherit this regression. But we can always revisit the work-around if we determine that to be the case. I'm starting Ubuntu22 testing now, so I may have an answer soon. Thanks, Jake ________________________________ From: Jake Garver <j...@nvidia.com> Sent: Friday, October 27, 2023 11:52 AM To: Ard Biesheuvel <a...@kernel.org>; Pedro Falcato <pedro.falc...@gmail.com> Cc: devel@edk2.groups.io <devel@edk2.groups.io>; rebe...@bsdio.com <rebe...@bsdio.com>; gaolim...@byosoft.com.cn <gaolim...@byosoft.com.cn>; bob.c.f...@intel.com <bob.c.f...@intel.com>; yuwei.c...@intel.com <yuwei.c...@intel.com> Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP Ard, Pedro, > Could you try adding -Wl,--no-relax to the DLINK_FLAGS for your build and see > if it makes a difference? With "-Wl,--no-relax", I still see an ADR instruction. Clean build. Verified the "-Wl,--no-relax" is part of the gcc all to build this dll. 0000000000002fec <fdt_path_offset>: 2fec: a9b97bfd stp x29, x30, [sp, #-112]! 2ff0: 910003fd mov x29, sp 2ff4: a90363f7 stp x23, x24, [sp, #48] 2ff8: aa0003f8 mov x24, x0 2ffc: 10020020 adr x0, 7000 <_cont+0xe98> 2ffc: R_AARCH64_ADR_GOT_PAGE __stack_chk_guard 3000: a90153f3 stp x19, x20, [sp, #16] 3004: aa0103f3 mov x19, x1 3008: f946cc00 ldr x0, [x0, #3480] 3008: R_AARCH64_LD64_GOT_LO12_NC __stack_chk_guard How do you think I should proceed? Thanks for all your help! Jake ________________________________ From: Ard Biesheuvel <a...@kernel.org> Sent: Friday, October 27, 2023 10:43 AM To: Pedro Falcato <pedro.falc...@gmail.com> Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Jake Garver <j...@nvidia.com>; rebe...@bsdio.com <rebe...@bsdio.com>; gaolim...@byosoft.com.cn <gaolim...@byosoft.com.cn>; bob.c.f...@intel.com <bob.c.f...@intel.com>; yuwei.c...@intel.com <yuwei.c...@intel.com> Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP External email: Use caution opening links or attachments On Fri, 27 Oct 2023 at 16:26, Pedro Falcato <pedro.falc...@gmail.com> wrote: > > On Fri, Oct 27, 2023 at 3:13 PM Ard Biesheuvel <a...@kernel.org> wrote: > > > > On Fri, 27 Oct 2023 at 16:09, Jake Garver via groups.io > > <jake=nvidia....@groups.io> wrote: > > > > > > Hi Ard: > > > > > > > Can you double check the object file? I suspect this is a linker > > > > relaxation 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. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110524): https://edk2.groups.io/g/devel/message/110524 Mute This Topic: https://groups.io/mt/102202314/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
