On Thu, Oct 26, 2023 at 4:32 PM Jake Garver via groups.io <jake=nvidia....@groups.io> wrote: > > In the R_AARCH64_ADR_GOT_PAGE case on AARCH64, be sure to change the > opcode to ADRP. Prior to this change, we updated the address, but not > the opcode. > > This resolves an issue experienced when building a StandaloneMm image > with stack protection enabled on GCC 10.5. This scenario generates an > ADR where an ADRP is more common in other versions of GCC tested. That > explains the obscurity of the issue. However, an ADR is valid and > should be handled by GenFw.
Is this not a toolchain bug? The aarch64 ELF ABI (https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst) says: "Set the immediate value of an ADRP to bits [32:12] of X; check that –232 <= X < 232" So it mentions this relocation pointing *to an ADRP* specifically. And AFAIK there's no way Page(G(GDAT(S+A)))-Page(P) would ever make sense if we're looking at an adr and not an adrp. Can you post the full disassembly for the function, plus relevant relocations? -- Pedro -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110140): https://edk2.groups.io/g/devel/message/110140 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] -=-=-=-=-=-=-=-=-=-=-=-
