public inbox for gdb-prs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>
To: gdb-prs@sourceware.org
Subject: [Bug breakpoints/12464] breakpoint number cannot be accessed from "commands" body
Date: Sat, 19 Nov 2022 13:54:24 +0000	[thread overview]
Message-ID: <bug-12464-4717-56KxXNakJ9@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-12464-4717@http.sourceware.org/bugzilla/>

https://sourceware.org/bugzilla/show_bug.cgi?id=12464

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Philippe Waroquiers
<philippe@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=78805ff8aecf0a8c828fb1e2c344fa3a56655120

commit 78805ff8aecf0a8c828fb1e2c344fa3a56655120
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date:   Sat May 23 22:27:28 2020 +0200

    Show locno for 'multi location' breakpoint hit msg+conv var $_hit_bbnum
$_hit_locno PR breakpoints/12464

    This implements the request given in PR breakpoints/12464.

    Before this patch, when a breakpoint that has multiple locations is
reached,
    GDB printed:
      Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5

    This patch changes the message so that bkpt_print_id prints the precise
    encountered breakpoint:
      Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5

    In mi mode, bkpt_print_id also (optionally) prints a new table field
"locno":
      locno is printed when the breakpoint hit has more than one location.
    Note that according to the GDB user manual node 'GDB/MI Development and
Front
    Ends', it is ok to add new fields without changing the MI version.

    Also, when a breakpoint is reached, the convenience variables
    $_hit_bpnum and $_hit_locno are set to the encountered breakpoint number
    and location number.

    $_hit_bpnum and $_hit_locno can a.o. be used in the command list of a
    breakpoint, to disable the specific encountered breakpoint, e.g.
       disable $_hit_bpnum.$_hit_locno

    In case the breakpoint has only one location, $_hit_locno is set to
    the value 1, so as to allow a command such as:
      disable $_hit_bpnum.$_hit_locno
    to disable the breakpoint even when the breakpoint has only one location.

    This also fixes a strange behaviour: when a breakpoint X has only
    one location,
      enable|disable X.1
    is accepted but transforms the breakpoint in a multiple locations
    breakpoint having only one location.

    The changes in RFA v4 handle the comments of Tom Tromey:
     - Changed convenience var names from $bkptno/$locno to
       $_hit_bpnum/$_hit_locno.
     - updated the tests and user manual accordingly.
       User manual also explictly describes that $_hit_locno is set to 1
       for a breakpoint with a single location.
     - The variable values are now set in bpstat_do_actions_1 so that
       they are set for silent breakpoints, and when several breakpoints
       are hit at the same time, that the variables are set to the printed
       breakpoint.

    The changes in RFA v3 handle the additional comments of Eli:
     GDB/NEW:
      - Use max 80-column
      - Use 'code location' instead of 'location'.
      - Fix typo $bkpno
      - Ensure that disable $bkptno and disable $bkptno.$locno have
        each their explanation inthe example
      - Reworded the 'breakpoint-hit' paragraph.
     gdb.texinfo:
      - Use 'code location' instead of 'location'.
      - Add a note to clarify the distinction between $bkptno and $bpnum.
      - Use @kbd instead of examples with only one command.

    Compared to RFA v1, the changes in v2 handle the comments given by
    Keith Seitz and Eli Zaretskii:
      - Use %s for the result of paddress
      - Use bkptno_numopt_re instead of 2 different -re cases
      - use C@t{++}
      - Add index entries for $bkptno and $locno
      - Added an example for "locno" in the mi interface
      - Added examples in the Break command manual.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

  reply	other threads:[~2022-11-19 13:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-04 18:45 [Bug breakpoints/12464] New: " rtc at gmx dot de
2022-11-19 13:54 ` cvs-commit at gcc dot gnu.org [this message]
2022-11-19 14:03 ` [Bug breakpoints/12464] " philippe.waroquiers at skynet dot be

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-12464-4717-56KxXNakJ9@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: link
Be 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).