public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "keno at juliacomputing dot com" <sourceware-bugzilla@sourceware.org> To: gdb-prs@sourceware.org Subject: [Bug remote/25741] New: GDB tries to set breakpoint using Z0, but remove it using z1 Date: Sat, 28 Mar 2020 01:34:45 +0000 [thread overview] Message-ID: <bug-25741-4717@http.sourceware.org/bugzilla/> (raw) https://sourceware.org/bugzilla/show_bug.cgi?id=25741 Bug ID: 25741 Summary: GDB tries to set breakpoint using Z0, but remove it using z1 Product: gdb Version: HEAD Status: UNCONFIRMED Severity: normal Priority: P2 Component: remote Assignee: unassigned at sourceware dot org Reporter: keno at juliacomputing dot com Target Milestone: --- I'm using GDB to talk to the rr (github.com/mozilla/rr) remote server. In one particular instance, I'm experiencing what I believe to be a bug in GDB. In particular, if I print out the GDB remote log (`set debug remote 1`), I see in relevant part (extracting all Zz packets): ``` (gdb) set debug remote 1 (gdb) handle SIGSEGV pass nostop noprint Signal Stop Print Pass to program Description SIGSEGV No No Yes Segmentation fault (gdb) handle SIGTRAP pass nostop noprint SIGTRAP is used by the debugger. Are you sure you want to change it? (y or n) y Signal Stop Print Pass to program Description SIGTRAP No No Yes Trace/breakpoint trap (gdb) hbreak *0xf7f736db Sending packet: $mf7f736db,1#33...Packet received: E01 Hardware assisted breakpoint 1 at 0xf7f736db (gdb) c Continuing. Sending packet: $Z1,f7f736db,1#7d...Packet received: OK Packet Z1 (hardware-breakpoint) is supported [...] Sending packet: $z1,f7f736db,1#9d...Packet received: OK [...] Sending packet: $Z0,f7f736db,1#7c...Packet received: OK Packet Z0 (software-breakpoint) is supported [...] Breakpoint 1, 0xf7f736db in ?? () (gdb) c [...] Sending packet: $z1,f7f736db,1#9d... ``` Full log at: https://gist.github.com/Keno/5c8345356d3124419bdfb8a80173c7a3. In particular, note that after hitting the watchpoint, GDB tries to re-establish the watchpoint with `Z0` rather than `Z1`. This causes rr to complain on the subsequent `z1` (since no such watchpoint was set only a sw breakpoint). The above trace if from GDB HEAD, compiled just now: GNU gdb (GDB) 10.0.50.20200328-git but I originally saw the issue in the GDB that ships with my OS: GNU gdb (Ubuntu 9.0.50.20191119-0ubuntu1) 9.0.50.20191119-git I have also reported this issue to rr at https://github.com/mozilla/rr/issues/2474, though I believe it is likely to be a GDB issue. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2020-03-28 1:34 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-03-28 1:34 keno at juliacomputing dot com [this message] 2020-03-28 4:01 ` [Bug remote/25741] " keno at juliacomputing dot com 2020-03-31 0:17 ` cbiesinger at google dot com 2020-04-07 2:28 ` keno at juliacomputing dot com 2020-05-17 18:24 ` cvs-commit at gcc dot gnu.org 2020-06-13 11:45 ` palves at redhat dot com
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-25741-4717@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).