Debugging a crash caused during the compilation of emulators/uae on armv7 FreeBSD 14.2, it appears that devel/llvm15 generates wrong code for stack checks. The cc we ship with base generates this sort of code in main: 00000000 <main>: 0: e92d4ff0 push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 4: e28db01c add r11, sp, #28 8: e24dd004 sub sp, sp, #4 c: ed2d8b04 vpush {d8, d9} 10: e24dde19 sub sp, sp, #400 14: e3000000 movw r0, #0x0 00000014: R_ARM_MOVW_ABS_NC __stack_chk_guard 18: e3400000 movt r0, #0x0 00000018: R_ARM_MOVT_ABS __stack_chk_guard 1c: e5900000 ldr r0, [r0] 20: e50b0038 str r0, [r11, #-0x38] i.e. the stack check guard token is loaded from __stack_chk_guard and then saved on the stack. When compiling the same file with devel/llvm15, I get this however: 00000000 <main>: 0: e92d4ff0 push {r4, r5, r6, r7, r8, r9, r10, r11, lr} 4: e28db01c add r11, sp, #28 8: e24dd004 sub sp, sp, #4 c: ed2d8b04 vpush {d8, d9} 10: e24ddf72 sub sp, sp, #456 14: e3000000 movw r0, #0x0 00000014: R_ARM_MOVW_ABS_NC __stack_chk_guard 18: e3400000 movt r0, #0x0 00000018: R_ARM_MOVT_ABS __stack_chk_guard 1c: e5900000 ldr r0, [r0] 20: e5900000 ldr r0, [r0] 24: e50b0038 str r0, [r11, #-0x38] This code differs in that there is an extra dereference of __stack_chk_guard. As __stack_chk_guard holds a random number, this dereference is unlikely to go right, crashing the program. Please investigate.
In the interest of being transparent, there is no chance I will look into this in any detail. I'm happy to apply a patch, but I'm not going to do the work of bisecting to find which of the probably 200K commits between llvm15 and llvm19 fixes this.
(In reply to Brooks Davis from comment #1) That's ok. Do you think this is an upstream issue? If yes, I'll gladly open an upstream PR and let them figure it out.
We're not doing much in the way of patching for armv7 so it's probably an upstream bug. Given it's working in the latest version I'm not sure if you will have much luck getting someone's attention, but it's always possible an Arm dev will remember which commit fixes it. Ultimately emulators/uae needs to be fixed to work with a modern llvm if it will eventually be reaped.
(In reply to Brooks Davis from comment #3) I have already patched out the llvm dependency in emulators/uae. It wasn't really required. However, other ports might still affected and I'm beginning to suspect that at least some of the weird segfaults I keep seeing could be related to this issue.