Re: template breakpoints

["Douglas Evans" <dje at google dot com>]

On 10/9/07, Vladimir Prus <vladimir@codesourcery.com> wrote:
>
> 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.


The phrasing here is a bit confusing.  Did you mean per-location here
(^^^^) ?  [I'm not suggesting an opinion on what it should be, just
trying to understand the current plan.]


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

Thanks.  I'm all for a good u/i.  At the moment I'm just trying to
understand what the plan is going forward.

How about breakpoint commands?  Are they considered akin to conditions
(and thus the plan is to leave them as is)?