[RFA,v3] enable/disable sub breakpoint range

  Allow enabling/disabling breakpoint location range

In some cases, adding one breakpoint corresponds to multiple
places in a program thus leads GDB to define main breakpoint
number and other breakpoints using location number with syntax:

<breakpoint_number>.<location_number>

For example:
Num  Type       Disp Enb  Address    What
1    breakpoint keep y    <MULTIPLE>
1.1                  y    0x080486a2 in void foo<int>()...
1.2                  y    0x080486ca in void foo<double>()...

In this example, main breakpoint is breakpoint 1 where location
breakpoints are 1.1 and 1.2 ones.

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

gdb/ChangeLog:

     * breakpoint.c (map_breakpoint_number_range): Create from
     map_breakpoint_numbers refactoring.
     (map_breakpoint_numbers): Refactor by calling
     map_breakpoint_number_range.
     (find_location_by_number): Change parameters from string to
     breakpoint number and location.
     (extract_bp_number_and_location): New function.
     (enable_disable_bp_num_loc): Create from enable/disable_command
     refactoring.
     (enable_disable_command): Create from enable/disable_command
     refactoring.
     (enable_command): Refactor using enable_disable_command.
     (disable_command): Refactor using enable_disable_command.
     * NEWS: Document enable/disable location range feature.

gdb/doc/ChangeLog:

     * gdb.texinfo (Set Breaks): Add documentation for location
     breakpoint range enable/disable action.

gdb/testsuite/ChangeLog:

     * gdb.cp/locbprange.exp: New test scenario.
     * gdb.cp/locbprange.cc: New test.

+    "breakpoint info disable 2.8 to 2.6"
  

> 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"?

> --- a/gdb/NEWS
> +++ b/gdb/NEWS
> @@ -65,6 +65,11 @@ QStartupWithShell
>   * The "maintenance selftest" command now takes an optional argument to
>     filter the tests to be run.
> 
> +* Breakpoint commands accept location ranges.
> +
> +The breakpoint commands ``enable'', and ``disable'' now accept a
> +location range of breakpoints, e.g. ``1.3-5''.
> +

This part is OK.

> +@code{enable} and @code{disable} commands.  It's also possible to
> +@code{enable} and @code{disable} range of @var{location-number}
> +breakpoints using a @var{breakpoint-number} and two @var{location-number},
> +in increasing order, separated by a hyphen, like
> +‘@var{breakpoint-number}.5-7’.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This should be

  @kbd{@var{breakpoint-number}.@var{location-number1}-@var{location-number2}}

or

  @kbd{@var{breakpoint-number}.5-7}

(In general, if you find yourself using `..', "..", or any similar
quoting in a Texinfo source, you can be sure something's wrong ;-)

> +In this case, when a @var{location-number} range is given to this
> +command, all breakpoints belonging to this @var{breakpoint-number}
> +and inside that range are operated on.

It is always best to avoid passive tense, as using that tends to
produce unnecessarily complicated and cumbersome text.  Suggest to
reword:

  If you use such a range of location numbers, @value{GDBN} will act
  on all the breakpoints in that range.

> +Note that you cannot delete the individual locations from the list,
> +you can only delete the entire list of locations that belong to their
> +parent breakpoint (with the @kbd{delete @var{num}} command, where
> +@var{num} is the number of the parent breakpoint, 1 in the above example).
> +Disabling or enabling the parent breakpoint (@pxref{Disabling}) affects
> +all of the locations that belong to that breakpoint.

This is just a complicated way of saying that the 'delete' command
doesn't support location-ranges, right?  If so, why not just say so?

Thanks.
  

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
  

On 10/03/2017 05:02 PM, Pedro Alves wrote:
>> > 
>> > 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

Sorry, typo above in the last line.

I meant either:
 (gdb) delete 1.3 1.4 1.5 4 5
or:
 (gdb) delete 1.3-5 4-5

Thanks,
Pedro Alves
  

Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
> 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
> 

Yes that's how it is supposed to be used.
  

> Cc: gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 3 Oct 2017 17:02:17 +0100
> 
> > 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

This basically means I need to give up the ranges?  Too bad.

> 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.

Yes, I think so.  With a cross-reference to the "Set Breaks" section,
where the .loc thing is explained.
  

On 10/03/2017 05:33 PM, Eli Zaretskii wrote:
>> Cc: gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 3 Oct 2017 17:02:17 +0100
>>
>>> 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
> 
> This basically means I need to give up the ranges?  Too bad.

The second suggestion I gave uses equivalent ranges:

 (gdb) delete 1.3-5 4-5

I don't understand why you say you have to give them up.

Thanks,
Pedro Alves
  

> Cc: roirand@adacore.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 3 Oct 2017 17:40:45 +0100
> 
>  (gdb) delete 1.3-5 4-5
> 
> I don't understand why you say you have to give them up.

Because I now need to break a single range into several ranges.

Wouldn't it be better to use 1.3-1.5 for the subranges, and then we
could still say 1.3-5 to mean all the breakpoints between 1.3 and 5?
  

On 10/03/2017 06:00 PM, Eli Zaretskii wrote:
>> Cc: roirand@adacore.com, gdb-patches@sourceware.org
>> From: Pedro Alves <palves@redhat.com>
>> Date: Tue, 3 Oct 2017 17:40:45 +0100
>>
>>  (gdb) delete 1.3-5 4-5
>>
>> I don't understand why you say you have to give them up.
> 
> Because I now need to break a single range into several ranges.
> 
> Wouldn't it be better to use 1.3-1.5 for the subranges, and then we
> could still say 1.3-5 to mean all the breakpoints between 1.3 and 5?

IMO, I'd rather not treat treat locations as decimals.
If we supported that, then we'd naturally want to support 1.3-4.5 as 
well as meaning all locations from 1.3 to 4.5.  I don't think
that that's going to be a normal use case at all.  Usually you'll
set a breakpoint, and then look at the list of created locations
and disable a few, all for the same breakpoint.

Also, I think it'd be very confusing if we broke from how
we treat sub ranges in other commands (such as thread ids).

And also, if we ever come up with some object as is more than
2 levels deep, like e.g., A.B.C, then I think range specifiers like 
A.B.C1-C2 is much more friendly to type (and easier to implement)
than A.B.C1-A.B.C2.

Thanks,
Pedro Alves
  

> Cc: roirand@adacore.com, gdb-patches@sourceware.org
> From: Pedro Alves <palves@redhat.com>
> Date: Tue, 3 Oct 2017 18:15:39 +0100
> 
> > Wouldn't it be better to use 1.3-1.5 for the subranges, and then we
> > could still say 1.3-5 to mean all the breakpoints between 1.3 and 5?
> 
> IMO, I'd rather not treat treat locations as decimals.

Fair enough.  Let me just say that, as a user, the notion that 1.3-5
actually 'expands" into "1.3 1.4 1.5" is extremely surprising, as
that's not what I'm used to in other similar situations.  But maybe
I'm just the odd one out.
  

Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
> 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 >

We have several ways for achieving this, especially when taking the 
C++ization of the code in account. What do you think would be the best 
approach:

- commit patch I've done as a first step, then propose a new patch 
including '.*' support ?

- write a breakpoint location range parser similar to the tid (for 
thread) one in pure C style including the '.*' support ? In that case 
what about the C++ization ? Would it be done in the future ?

- Change the patch I've proposed to integrate '.*' support in the new 
C++ style function I wrote ?

Something else ?

Regards.
  

On Fri, 2017-10-06 at 10:54 +0200, Xavier Roirand wrote:
> Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
> > 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 >
> 
> We have several ways for achieving this, especially when taking the 
> C++ization of the code in account. What do you think would be the
> best 
> approach:
> 
> - commit patch I've done as a first step, then propose a new patch 
> including '.*' support ?
> 
> - write a breakpoint location range parser similar to the tid (for 
> thread) one in pure C style including the '.*' support ? In that
> case 
> what about the C++ization ? Would it be done in the future ?
> 
> - Change the patch I've proposed to integrate '.*' support in the
> new 
> C++ style function I wrote ?
> 
> Something else ?
IMO, if there are a number of breakpoint related commands that benefits
from breakpoints range and/or breakpoints location range, a C++ parser
inspired from tid parser looks a good approach.

Today, however, it looks like only the enable/disable commands
are accepting a bp loc.

We might envisage to convert other commands to work on bp loc
rather than on bp, but that looks like a much bigger work.
For example, 'commands' today associates the list of commands to
run with the bp, and not with each bp loc.
Similarly, 'enable once' is on the bp, as the hit count is maintained
per bp, and not per bp loc. 
Same for 'condition', 'delete', 'enable count/delete/once'

So, with the current state of the breakpoints related commands,
IIUC, only enable/disable are ready to work with bp loc.

When another breakpoint related command is converted to work on bp
loc, then a "general bp set/bp range/bp loc/bp loc range' parser would
be interesting.

In the meantime, it looks to me that 'perfect is the enemy of good'
and that the current V3 patch looks good enough for the moment.

My 2 cents ...

Philippe
Note: at my day job, I am a (paying) Adacore customer, and I suggested
to Adacore this enhancement of enable/disable to support bp loc ranges.
So, the above 2 cents opinion that the patch is good enough might be
somewhat biased.
  

Hello,

Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
> On 10/03/2017 03:50 PM, Eli Zaretskii wrote:
>>> From: Xavier Roirand <roirand@adacore.com>
> 
> 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.)
> 

Unfortunately I don't have enough time to work on a simplified version 
of the thread id number parsing in order to provide this enable/disable 
sub range feature. What I can add in my current patch is the support for 
.* notation if you think this is something really useful. Let me know 
what do you think so I can propose a new patch.

Regards.

> Thanks,
> Pedro Alves
>
  

On 10/20/2017 01:17 PM, Xavier Roirand wrote:
> Hello,
> 
> Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
>> On 10/03/2017 03:50 PM, Eli Zaretskii wrote:
>>>> From: Xavier Roirand <roirand@adacore.com>
>>
>> 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.)
>>
> 
> Unfortunately I don't have enough time to work on a simplified version
> of the thread id number parsing in order to provide this enable/disable
> sub range feature. What I can add in my current patch is the support for
> .* notation if you think this is something really useful. Let me know
> what do you think so I can propose a new patch.

Eh, I never suggested to add the '*' parsing.  Above I explicitly
pointed at the commit _before_ that, even, so you could see how the
documentation looked like then.

Thanks,
Pedro Alves
  

On 10/20/2017 03:41 PM, Pedro Alves wrote:
> On 10/20/2017 01:17 PM, Xavier Roirand wrote:
>> Hello,
>>
>> Le 10/3/17 à 6:02 PM, Pedro Alves a écrit :
>>> On 10/03/2017 03:50 PM, Eli Zaretskii wrote:
>>>>> From: Xavier Roirand <roirand@adacore.com>
>>>
>>> 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.)
>>>
>>
>> Unfortunately I don't have enough time to work on a simplified version
>> of the thread id number parsing in order to provide this enable/disable
>> sub range feature. What I can add in my current patch is the support for
>> .* notation if you think this is something really useful. Let me know
>> what do you think so I can propose a new patch.
> 
> Eh, I never suggested to add the '*' parsing.  Above I explicitly
> pointed at the commit _before_ that, even, so you could see how the
> documentation looked like then.

I'm having trouble applying your patch locally.  Saving your email
as an mbox file and then using 'git am' gets me:

$ git am /tmp/bps.mbox
Applying: enable/disable sub breakpoint range
/home/pedro/gdb/mygit/src/.git/rebase-apply/patch:25: trailing whitespace.
static void map_breakpoint_number_range (std::pair <int, int>
fatal: corrupt patch at line 26
Patch failed at 0001 enable/disable sub breakpoint range
The copy of the patch that failed is found in:
   /home/pedro/gdb/mygit/src/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

I tried fixing it manually, but failed.  I also tried creating
a patch from the email's rendered content but failed to apply
too.  :-/

Could you resend with git send-email?  That would be best.
Or, as an attachment?
(In any case, if rebased to current master too then
that'd be appreciated.)

Thanks,
Pedro Alves