Iain Sandoe <idsan...@googlemail.com> writes: > Hi Folks, > > On the Darwin aarch64 port, we have a number of cleanup test fails (pretty > much corresponding to the [still open] > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39244). However, let’s assume > that bug could be a red herring.. > > the underlying reason is missing CFI for the set of the FP which [with > Darwin’s LLVM libunwind impl.] breaks the unwind through the function that > triggers a signal.
Just curious, do you have more details about why that is? If the unwinder is sophisticated enough to process CFI, it seems odd that it requires the CFA to be defined in terms of the frame pointer. > > ——— > > taking one of the functions in cleanup-8.C (say fn1) which contains calls. > > what I am seeing is something like: > > __ZL3fn1v: > LFB28: > ; BLOCK 2, count:1073741824 (estimated locally) seq:0 > ; PRED: ENTRY [always] count:1073741824 (estimated locally, freq 1.0000) > (FALLTHRU) > stp x29, x30, [sp, -32]! > // LCFI; or .cfi_xxx is present > mov x29, sp > // *** NO LCFI (or .cfi_cfa_xxxx when that is enabled) > str x19, [sp, 16] > // LCFI / .cfi_xxxx is present. > adrp x19, __ZL3fn4i@PAGE > add x19, x19, __ZL3fn4i@PAGEOFF;momd > mov x1, x19 > mov w0, 11 > bl _signal > <snip> > > ——— > > The reason seems to be that, in expand_prolog, emit_frame_chain is true (as > we would expect, given that this function makes calls). However > ‘frame_pointer_needed' is false, so that the call to aarch64_add_offset() > [line aarch64.cc:10405] does not add CFA adjustments to the load of x29. Right. > ——— > > I have currently worked around this by defining a > TARGET_FRAME_POINTER_REQUIRED which returns true unless the function is a > leaf (if that’s the correct solution, then all is fine). I suppose it depends on why the frame-pointer-based CFA is important for Darwin. If it's due to a more general requirement for a frame pointer to be used, then yeah, that's probably the right fix. If it's more a quirk of the unwinder. then we could probably expose whatever that quirk is as a new status bit. Target-independent code in dwarf2cfi.cc would then need to be aware as well. > ——— > > However, it does seem odd that the existing code sets up the FP, but never > produces any CFA for it. > > So is this a possible bug, or just that I misunderstand the relevant set of > circumstances? emit_frame_chain fulfills an ABI requirement that every non-leaf function set up a frame-chain record. When emit_frame_chain && !frame_pointer_needed, we set up the FP for ABI purposes only. GCC can still access everything relative to the stack pointer, and it can still describe the CFI based purely on the stack pointer. glibc-based systems only need the CFA to be based on the frame pointer if the stack pointer moves during the body of the function (usually due to alloca or VLAs). Thanks, Richard
