Re: Question on aarch64 prologue code.

[Richard Sandiford <richard.sandiford@arm.com>]

Iain Sandoe <idsandoe@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