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 <ardb@kernel.org>
Sent: Friday, October 27, 2023 10:43 AM
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: devel@edk2.groups.io <devel@edk2.groups.io>; Jake Garver <jake@nvidia.com>; rebecca@bsdio.com <rebecca@bsdio.com>; gaoliming@byosoft.com.cn <gaoliming@byosoft.com.cn>; bob.c.feng@intel.com <bob.c.feng@intel.com>; yuwei.chen@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 <pedro.falcato@gmail.com> wrote:
>
> On Fri, Oct 27, 2023 at 3:13 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Fri, 27 Oct 2023 at 16:09, Jake Garver via groups.io
> > <jake=nvidia.com@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.