From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 520E53858D3C; Fri, 24 Sep 2021 22:51:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 520E53858D3C From: "wilson at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/28371] gdb: watchpoint for local variable doesn't work on RISC-V Date: Fri, 24 Sep 2021 22:51:36 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: wilson at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2021 22:51:36 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28371 Jim Wilson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- I can reproduce natively on an Unmatched with the SiFive OpenEmbedded distr= o.=20 Looking at the gcc and clang output. I see that the epilogue for func2 in = the gcc output is ld s0,24(sp) .cfi_restore 8 .cfi_def_cfa 2, 32 addi sp,sp,32 .cfi_def_cfa_offset 0 jr ra .cfi_endproc And the epilogue for func2 in the clang output is ld s0, 16(sp) # 8-byte Folded Reload ld ra, 24(sp) # 8-byte Folded Reload addi sp, sp, 32 ret .Ltmp3: .Lfunc_end1: .size func2, .Lfunc_end1-func2 .cfi_endproc So the clang output has no unwind info for epilogues. I believe that is a known problem with clang. Somehow this lack of epilogue unwind info is confusing gdb, and it thinks t= hat the variable q has gone out of scope when it sees the frame pointer popped = from the stack without corresponding unwind info. This makes some sense, since = gdb has to parse the frame to find the local q in the parent function, and if t= he unwind info is wrong it won't be able to do that. I don't know if this can be fixed in gdb. It can certainly be fixed in cla= ng by emitting unwind info for function epilogues. Also note that if you put a breakpoint in the func2 epilogue and type the "= up" command, this works with the gcc output, taking you to main, but fails in t= he clang output, taking you to __libc_start_call_main which is a glibc functio= n.=20 Epilogue unwind info is needed for this to work right also. This whole mess is probably complicated by the fact that we don't have hard= ware watchpoints (except with openocd), so we have to single step through code a= nd check for a change to q after every instruction. If we had hardware watchpoints, the watchpoint for q would work correctly. Without hardware watchpoints, we need function epilogue unwind info to be correct. --=20 You are receiving this mail because: You are on the CC list for the bug.=