Re: [RFA v3] enable/disable sub breakpoint range

[Pedro Alves <palves@redhat.com>]

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