From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id A0C693861893; Tue, 23 Mar 2021 17:20:28 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A0C693861893
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/99334] Generated DWARF unwind table issue while on
 instructions where rbp is pointing to callers stack frame
Date: Tue, 23 Mar 2021 17:20:28 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 9.2.0
X-Bugzilla-Keywords: wrong-debug
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 8.2
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-99334-4-ALRf9S7MkW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-99334-4@http.gcc.gnu.org/bugzilla/>
References: <bug-99334-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2021 17:20:28 -0000

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99334

--- 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 =3D false;

          add_cfi_insn =3D insn;
+
+         if (queued_reg_saves.length () && clobbers_queued_reg_save (insn))
+           dwarf2out_flush_queued_reg_saves ();
+
          scan_insn_after (insn);
          control =3D 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 rea=
lly
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.=