This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: PATCH: Remove dead code, clear breakpoint ignore counts?
>>>>> "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