This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: template breakpoints


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]