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 : 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 Sent: Friday, October 27, 2023 10:43 AM To: Pedro Falcato Cc: devel@edk2.groups.io ; Jake Garver ; rebecca@bsdio.com ; gaoliming@byosoft.com.cn ; bob.c.feng@intel.com ; yuwei.chen@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 wrote: > > On Fri, Oct 27, 2023 at 3:13 PM 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 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 (#110219): https://edk2.groups.io/g/devel/message/110219 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] -=-=-=-=-=-=-=-=-=-=-=-