Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Xavier Roirand <roirand@adacore.com>, gdb-patches@sourceware.org
Subject: Re: [RFA v3] enable/disable sub breakpoint range
Date: Mon, 16 Oct 2017 22:21:00 -0000	[thread overview]
Message-ID: <1508192463.28654.3.camel@skynet.be> (raw)
In-Reply-To: <7cf5c60b-4bab-1e91-61dd-f580bf417b12@adacore.com>

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.


  reply	other threads:[~2017-10-16 22:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-03 10:26 Xavier Roirand
2017-10-03 14:50 ` Eli Zaretskii
2017-10-03 16:02   ` Pedro Alves
2017-10-03 16:05     ` Pedro Alves
2017-10-03 16:06     ` Xavier Roirand
2017-10-03 16:34     ` Eli Zaretskii
2017-10-03 16:40       ` Pedro Alves
2017-10-03 17:00         ` Eli Zaretskii
2017-10-03 17:15           ` Pedro Alves
2017-10-03 18:32             ` Eli Zaretskii
2017-10-06  8:54     ` Xavier Roirand
2017-10-16 22:21       ` Philippe Waroquiers [this message]
2017-10-20 12:17     ` Xavier Roirand
2017-10-20 14:41       ` Pedro Alves
2017-10-20 14:58         ` Pedro Alves
     [not found]           ` <c1310ac2-b958-f0b6-aabd-5f14f8524b79@adacore.com>
2017-10-23 10:25             ` [RFA v4] " Pedro Alves
2017-10-23 11:07               ` Xavier Roirand
2017-10-26 13:11                 ` Pedro Alves

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=1508192463.28654.3.camel@skynet.be \
    --to=philippe.waroquiers@skynet.be \
    --cc=gdb-patches@sourceware.org \
    --cc=roirand@adacore.com \
    /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