Re: PATCH: Remove dead code, clear breakpoint ignore counts?

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

Pedro> Seems like it.  :-) I guess I wasn't that clear, but the actual
Pedro> code that initialy bothered me was the clearing the *ignore*
Pedro> counts in generic_mourn_inferior, or better, the comment there
Pedro> that I must have read a hundred times already by now, although
Pedro> it's dead code.

I say just nuke it.  If it has been dead for 14 years, then nobody
cares.

Pedro> Just curious, do people think that it's useful to clear the hit
Pedro> count automatically at all, considering that we do it on "run" but not
Pedro> on "attach" or "target remote"?

I occasionally use this feature to figure out how I ought to set
ignore counts.  E.g., set a breakpoint, run, "c 99999", wait for the
crash, and then ignore one less than the hit count.

This idiom relies on re-running, so it is not very useful with attach.

I guess it is tough to change behavior that has been deployed for many
years, since it is hard to guess how people are using it.

Pedro> I can't seem to make up my mind on it.  It's still logicaly the
Pedro> same breakpoint across runs, so it could make sense to not do
Pedro> so.

Offhand I could not think of a way I would use the hit count if it
were not auto-cleared.  When would I want to know the accumulated
total of hits across all runs?

Stan> Hit counts are going to get a little messy for multi-process, because 
Stan> each inferior could have a different hit count, and it seems more useful 
Stan> to have a per-inferior hit count than an aggregate over all the 
Stan> inferiors to which the breakpoint applies.

Pedro> Right, that would mean storing a hit count per-breakpoint
Pedro> location as well as per-breakpoint, it seems.  Same for ignore
Pedro> counts.

I would probably just set a breakpoint specific to a particular
inferior if I was worried about this case.

Tom