Thanks for your response, Pedro. I chased this as a toolchain bug originally, but concluded that the ADR indeed works before GenFw rewrites it. But I see your point regarding the relocation statement. As requested, below is the disassembled function along with relocations. This was generated from the dll using "aarch64-linux-gnu-objdump -r -D". The ADR in question is at 2ffc. This code was generated by the current version of the GCC 10.x toolchain on Ubuntu20. So, if we're concluding this is a toolchain issue, then it's with a fairly "stock" toolchain. 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 300c: a9025bf5 stp x21, x22, [sp, #32] 3010: a9046bf9 stp x25, x26, [sp, #64] 3014: f9002bfb str x27, [sp, #80] 3018: f9400001 ldr x1, [x0] 301c: f90037e1 str x1, [sp, #104] 3020: d2800001 mov x1, #0x0 // #0 3024: aa1303e0 mov x0, x19 3028: 97fffd04 bl 2438 3028: R_AARCH64_CALL26 .text+0x1438 302c: aa0003f5 mov x21, x0 3030: aa1803e0 mov x0, x24 3034: 97fff807 bl 1050 3034: R_AARCH64_CALL26 .text+0x50 3038: 2a0003f4 mov w20, w0 303c: 35000260 cbnz w0, 3088 3040: 39400260 ldrb w0, [x19] 3044: 93407ea1 sxtw x1, w21 3048: 8b35c275 add x21, x19, w21, sxtw 304c: 7100bc1f cmp w0, #0x2f 3050: 54000420 b.eq 30d4 // b.none 3054: 528005e2 mov w2, #0x2f // #47 3058: aa1303e0 mov x0, x19 305c: 97ffff2f bl 2d18 305c: R_AARCH64_CALL26 .text+0x1d18 3060: f100001f cmp x0, #0x0 3064: 9a951016 csel x22, x0, x21, ne // ne = any 3068: f0000001 adrp x1, 6000 <__stack_chk_fail+0x7c> 3068: R_AARCH64_ADR_PREL_PG_HI21 .text+0x58b6 306c: 9122d821 add x1, x1, #0x8b6 306c: R_AARCH64_ADD_ABS_LO12_NC .text+0x58b6 3070: aa1803e0 mov x0, x24 3074: cb1302d4 sub x20, x22, x19 3078: 97ffffdd bl 2fec 307c: 2a0003e1 mov w1, w0 3080: 36f80140 tbz w0, #31, 30a8 3084: 12800094 mov w20, #0xfffffffb // #-5 3088: 90000020 adrp x0, 7000 <_cont+0xe98> 3088: R_AARCH64_ADR_GOT_PAGE __stack_chk_guard 308c: f946cc00 ldr x0, [x0, #3480] 308c: R_AARCH64_LD64_GOT_LO12_NC __stack_chk_guard 3090: f94037e1 ldr x1, [sp, #104] 3094: f9400002 ldr x2, [x0] 3098: eb020021 subs x1, x1, x2 309c: d2800002 mov x2, #0x0 // #0 30a0: 54000a00 b.eq 31e0 // b.none 30a4: 94000bb8 bl 5f84 <__stack_chk_fail> 30a4: R_AARCH64_CALL26 __stack_chk_fail 30a8: 2a1403e3 mov w3, w20 30ac: aa1303e2 mov x2, x19 30b0: aa1803e0 mov x0, x24 30b4: d2800004 mov x4, #0x0 // #0 30b8: 97ffff72 bl 2e80 30b8: R_AARCH64_CALL26 .text+0x1e80 30bc: b4fffe40 cbz x0, 3084 30c0: 91003001 add x1, x0, #0xc 30c4: aa1603f3 mov x19, x22 30c8: aa1803e0 mov x0, x24 30cc: 97ffffc8 bl 2fec 30d0: 2a0003f4 mov w20, w0 30d4: 910193fa add x26, sp, #0x64 30d8: 14000037 b 31b4 30dc: 910006d6 add x22, x22, #0x1 30e0: eb1602bf cmp x21, x22 30e4: 54fffd20 b.eq 3088 // b.none 30e8: 394002c0 ldrb w0, [x22] 30ec: 7100bc1f cmp w0, #0x2f 30f0: 54ffff60 b.eq 30dc // b.none 30f4: cb1602a1 sub x1, x21, x22 30f8: aa1603e0 mov x0, x22 30fc: 528005e2 mov w2, #0x2f // #47 3100: 97ffff06 bl 2d18 3100: R_AARCH64_CALL26 .text+0x1d18 3104: f100001f cmp x0, #0x0 3108: 9a951013 csel x19, x0, x21, ne // ne = any 310c: aa1803e0 mov x0, x24 3110: 97fff7d0 bl 1050 3110: R_AARCH64_CALL26 .text+0x50 3114: 35000620 cbnz w0, 31d8 3118: 4b160277 sub w23, w19, w22 311c: b90067ff str wzr, [sp, #100] 3120: 110006fb add w27, w23, #0x1 3124: 93407ef7 sxtw x23, w23 3128: b94067e0 ldr w0, [sp, #100] 312c: 7100029f cmp w20, #0x0 3130: 7a40a801 ccmp w0, #0x0, #0x1, ge // ge = tcont 3134: 5400008a b.ge 3144 // b.tcont 3138: 36f803c0 tbz w0, #31, 31b0 313c: 12800014 mov w20, #0xffffffff // #-1 3140: 17ffffd2 b 3088 3144: 7100041f cmp w0, #0x1 3148: 540000e0 b.eq 3164 // b.none 314c: 2a1403e1 mov w1, w20 3150: aa1a03e2 mov x2, x26 3154: aa1803e0 mov x0, x24 3158: 97fff87c bl 1348 3158: R_AARCH64_CALL26 .text+0x348 315c: 2a0003f4 mov w20, w0 3160: 17fffff2 b 3128 3164: 2a1b03e2 mov w2, w27 3168: 11001281 add w1, w20, #0x4 316c: aa1803e0 mov x0, x24 3170: 97fff7da bl 10d8 3170: R_AARCH64_CALL26 .text+0xd8 3174: aa0003f9 mov x25, x0 3178: b4fffea0 cbz x0, 314c 317c: f10002ff cmp x23, #0x0 3180: fa4012c4 ccmp x22, x0, #0x4, ne // ne = any 3184: 54000201 b.ne 31c4 // b.any 3188: 38776b20 ldrb w0, [x25, x23] 318c: 34000120 cbz w0, 31b0 3190: aa1703e1 mov x1, x23 3194: aa1603e0 mov x0, x22 3198: 52800802 mov w2, #0x40 // #64 319c: 97fffedf bl 2d18 319c: R_AARCH64_CALL26 .text+0x1d18 31a0: b5fffd60 cbnz x0, 314c 31a4: 38776b20 ldrb w0, [x25, x23] 31a8: 7101001f cmp w0, #0x40 31ac: 54fffd01 b.ne 314c // b.any 31b0: 37fff6d4 tbnz w20, #31, 3088 31b4: eb1302bf cmp x21, x19 31b8: 54fff689 b.ls 3088 // b.plast 31bc: aa1303f6 mov x22, x19 31c0: 17ffffca b 30e8 31c4: aa1703e2 mov x2, x23 31c8: aa1603e1 mov x1, x22 31cc: 97fffef7 bl 2da8 31cc: R_AARCH64_CALL26 .text+0x1da8 31d0: 35fffbe0 cbnz w0, 314c 31d4: 17ffffed b 3188 31d8: 2a0003f4 mov w20, w0 31dc: 17fffff5 b 31b0 31e0: 2a1403e0 mov w0, w20 31e4: a94153f3 ldp x19, x20, [sp, #16] 31e8: a9425bf5 ldp x21, x22, [sp, #32] 31ec: a94363f7 ldp x23, x24, [sp, #48] 31f0: a9446bf9 ldp x25, x26, [sp, #64] 31f4: f9402bfb ldr x27, [sp, #80] 31f8: a8c77bfd ldp x29, x30, [sp], #112 31fc: d65f03c0 ret 3200: 14000400 b 4200 3204: d503201f nop 3208: f946cc00 ldr x0, [x0, #3480] 320c: 17ffff80 b 300c Jake ________________________________ From: Pedro Falcato Sent: Thursday, October 26, 2023 2:46 PM To: devel@edk2.groups.io ; Jake Garver Cc: rebecca@bsdio.com ; gaoliming@byosoft.com.cn ; bob.c.feng@intel.com ; yuwei.chen@intel.com ; ardb+tianocore@kernel.org Subject: Re: [edk2-devel] [PATCH] BaseTools/GenFw: Change opcode when converting ADR to ADRP External email: Use caution opening links or attachments On Thu, Oct 26, 2023 at 4:32 PM Jake Garver via 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FARM-software%2Fabi-aa%2Fblob%2Fmain%2Faaelf64%2Faaelf64.rst&data=05%7C01%7Cjake%40nvidia.com%7C607b433f7ddc40266e3c08dbd653f1c1%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638339428273243439%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6DcbbXjY4UfjTwAUpd525B%2BvqPEWkZ1RStdc62%2F2er4%3D&reserved=0) 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 (#110205): https://edk2.groups.io/g/devel/message/110205 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] -=-=-=-=-=-=-=-=-=-=-=-