This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA v3] enable/disable sub breakpoint range
- From: Pedro Alves <palves at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>, Xavier Roirand <roirand at adacore dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 3 Oct 2017 17:02:17 +0100
- Subject: Re: [RFA v3] enable/disable sub breakpoint range
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B06DBC04B333
- References: <b0b1d9bd-aa40-879c-3d2d-17e287488d2a@adacore.com> <83lgks1e1h.fsf@gnu.org>
On 10/03/2017 03:50 PM, Eli Zaretskii wrote:
>> From: Xavier Roirand <roirand@adacore.com>
>> Date: Tue, 3 Oct 2017 12:26:49 +0200
>>
>> This patch allows enable/disable a range of breakpoint locations
>> using syntax:
>>
>> <breakpoint_number>.<first_location_number>-<last_location_number>
>>
>> with inclusive last_location_number.
>>
>> For instance, if adding a breakpoint to foo() generates 5 breakpoint
>> locations from 1.1 to 1.5 then it's now possible to enable/disable
>> only location breakpoint 1.3 to location breakpoint 1.5
>> (so 1.3, 1.4 and 1.5) using syntax:
>>
>> enable 1.3-5 or disable 1.3-5
>
> What if I have, in addition to the 1.1-1.5 breakpoints also
> breakpoints 4, 5, and 6 -- how do I disable 1.3, 1.4, 1.5, 4, and 5?
> Do I have to say something like "disable 1.3-5.0"?
I hope not. Supposedly you could do it with:
(gdb) delete 1.3 1.4 1.5 4 5
or:
(gdb) delete 1-5 4-5
though I haven't looked at the implementation in detail.
I definitely thing the above is what we should aim for though.
It's very much what we support for thread ID lists, at least
(expect the support for thread ID star ranges).
I'm wondering whether it wouldn't be better to expand this section
of the manual:
@cindex breakpoint ranges
@cindex breakpoint lists
@cindex ranges of breakpoints
@cindex lists of breakpoints
Some @value{GDBN} commands accept a space-separated list of breakpoints
on which to operate. A list element can be either a single breakpoint number,
like @samp{5}, or a range of such numbers, like @samp{5-7}.
When a breakpoint list is given to a command, all breakpoints in that list
are operated on.
To describe locations as well. Similarly to how we describe
"thread ID lists", where we have:
@anchor{thread ID lists}
@cindex thread ID lists
Some commands accept a space-separated @dfn{thread ID list} as
argument. A list element can be:
@enumerate
@item
A thread ID as shown in the first field of the @samp{info threads}
display, with or without an inferior qualifier. E.g., @samp{2.1} or
@samp{1}.
@item
A range of thread numbers, again with or without an inferior
qualifier, as in @var{inf}.@var{thr1}-@var{thr2} or
@var{thr1}-@var{thr2}. E.g., @samp{1.2-4} or @samp{2-4}.
@item
All threads of an inferior, specified with a star wildcard, with or
without an inferior qualifier, as in @var{inf}.@code{*} (e.g.,
@samp{1.*}) or @code{*}. The former refers to all threads of the
given inferior, and the latter form without an inferior qualifier
refers to all threads of the current inferior.
@end enumerate
For example, if the current inferior is 1, and inferior 7 has one
thread with ID 7.1, the thread list @samp{1 2-3 4.5 6.7-9 7.*}
includes threads 1 to 3 of inferior 1, thread 5 of inferior 4, threads
7 to 9 of inferior 6 and all threads of inferior 7. That is, in
expanded qualified form, the same as @samp{1.1 1.2 1.3 4.5 6.7 6.8 6.9
7.1}.
Then commands that accept a thread ID list xref here.
We'd do the same to breakpoint commands, i.e., commands that take
an breakpoint/location list would xref the description of breakpoint
lists.
See commit 5d5658a1d3c3 ("Per-inferior/Inferior-qualified thread IDs")
for how that looked like before support for '*' ranges was added.
(And now I wonder whether it'd make sense to model the breakpoint
number parsing on a simplified version of the thread ID number
parsing. See gdb/tid-parse.h / tid_range_parser.)
Thanks,
Pedro Alves