https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I wonder about:
--- gcc/dwarf2cfi.c.jj 2021-03-02 11:25:47.217727061 +0100
+++ gcc/dwarf2cfi.c 2021-03-23 17:34:58.240281522 +0100
@@ -2705,12 +2705,15 @@ scan_trace (dw_trace_info *trace, bool e
dwarf2out_flush_queued_reg_saves ();
}
else if (!NONJUMP_INSN_P (insn)
- || clobbers_queued_reg_save (insn)
|| find_reg_note (insn, REG_CFA_FLUSH_QUEUE, NULL))
dwarf2out_flush_queued_reg_saves ();
any_cfis_emitted = false;
add_cfi_insn = insn;
+
+ if (queued_reg_saves.length () && clobbers_queued_reg_save (insn))
+ dwarf2out_flush_queued_reg_saves ();
+
scan_insn_after (insn);
control = insn;
}
For calls or REG_CFA_FLUSH_QUEUE I can understand wanting to flush queued
register saves after the previous instruction, but for clobbers_queued_reg_save
cases I don't understand that.
This is about the:
pushq %rbp
movq %rsp, %rbp
case. On pushq %rbp we queue the DW_CFA_expression for %rbp (but use %rbp in
the expression), then see clobbers_queued_reg_save (insn) on the movq %rsp,
%rbp
returning true because that instruction overwrites it. But as it isn't really
a call, I believe at least the libgcc unwinder for async signals evaluates all
FDE instructions until the current pc inclusive.
pushq %rbp doesn't really change %rbp and CFA is computed from %r10 at that
point, and when we are at the start of movq %rsp, %rbp, we still haven't
changed %rbp. As it is not a call, it doesn't have a separate byte abused for
in the middle of the instruction and so the only other possibility is after
that instruction.
