From: Vladimir Prus <vladimir@codesourcery.com>
To: "Douglas Evans" <dje@google.com>
Cc: gdb@sources.redhat.com
Subject: Re: template breakpoints
Date: Tue, 09 Oct 2007 17:57:00 -0000 [thread overview]
Message-ID: <200710092156.39099.vladimir@codesourcery.com> (raw)
In-Reply-To: <e394668d0710091044v10dfee5m17d30eaa263917ca@mail.gmail.com>
On Tuesday 09 October 2007 21:44:17 Douglas Evans wrote:
> On 10/8/07, Vladimir Prus <ghost@cs.msu.su> wrote:
> > On Tuesday 09 October 2007 02:35:35 Douglas Evans wrote:
> > > Hi. I downloaded and tried the new support. Nice. I noticed that
> > > while enable/disable work with the new "multiple breakpoints",
> > > condition/ignore/commands don't (currently) work. Is there a plan to
> > > support these with the new breakpoints as well?
> >
> > They are supposed to work. Can you provide a self-contained (source) program,
> > and a set of gdb commands that reproduce the problem?
>
> Appended is the session log. The testcase is testsuite/gdb.cp/mb-templates.cc.
>
> Note that in breakpoints.cc {enable,disable}_command do a strchr
> (args, '.') to watch for a.b spelled breakpoints where as
> {commands,ignore,condition}_command just call get_number. And
> delete_command calls get_number_or_range via map_breakpoint_numbers.
> [Assuming I'm reading the code correctly ...]
>
> Also, note that by "support" I mean one can, for example, set a
> condition on individual breakpoints within the multi-breakpoint(sp?).
> [Just making sure we're on the same page ...]
Ah, I see what you mean. As it stands now, condition, command, and ignore
count is per-breakpoint, not per-location. It was suggested that ignore count
and hit count be made per-breakpoint, but was outside the code of the original
work.
As for condition, I'm not sure. On code level it's not hard to support, but there
are issues.
First issue is technical. A breakpoint is reevaluated as any
shared library is loaded and unloaded. If you set per-location
condition, you probably want that condition to be still active
after the library containing the location is unloaded and reloaded
several time, and application restarted. To do that, we need to somehow
track location's identity, and I don't know 100% reliable solution.
We have similar problem with enable/disable state, but there, at worst
case you'll stop on location you don't care about. With per-location
condition, you can just loose your condition.
Another issue is "why?". Presumably, if you want a specific condition
for just one template instantiation, you can just set breakpoint on
that template instatiation? I basically worry that the user interface
will become too complex to be usable.
- Volodya
next prev parent reply other threads:[~2007-10-09 17:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-06 5:10 Douglas Evans
2007-10-06 10:43 ` Vladimir Prus
2007-10-06 18:09 ` Douglas Evans
2007-10-08 22:35 ` Douglas Evans
2007-10-09 4:57 ` Vladimir Prus
2007-10-09 17:44 ` Douglas Evans
2007-10-09 17:57 ` Vladimir Prus [this message]
2007-10-09 20:17 ` Douglas Evans
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=200710092156.39099.vladimir@codesourcery.com \
--to=vladimir@codesourcery.com \
--cc=dje@google.com \
--cc=gdb@sources.redhat.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