From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org, tromey@redhat.com
Cc: Stan Shebs <stanshebs@earthlink.net>
Subject: Re: PATCH: Remove dead code, clear breakpoint ignore counts?
Date: Tue, 14 Oct 2008 20:55:00 -0000 [thread overview]
Message-ID: <200810142155.10811.pedro@codesourcery.com> (raw)
In-Reply-To: <m33aizgd0f.fsf@fleche.redhat.com>
On Tuesday 14 October 2008 21:03:44, Tom Tromey wrote:
> >>>>> "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.
Yeah. I've just done so.
> 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 that comes from the fact that there's no easy way to reset the
hit count of the breakpoint (or of all breakpoints), other than
delete,re-create'ing it (them).
> 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.
Yeah.
> 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?
I dunno. I don't actually rely on those counters myself that often.
I was noticing that currently, in a multi-process GDB, if I do "run"
followed by another "run", while the first process is still live (I
don't kill it), all hit counts are being reset. That seemed wrong.
I guess we'll be getting back to this sooner or later. I'm happy
for now. :-)
Thanks!
--
Pedro Alves
prev parent reply other threads:[~2008-10-14 20:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-14 18:11 Pedro Alves
2008-10-14 18:33 ` Stan Shebs
2008-10-14 18:53 ` Pedro Alves
2008-10-14 20:10 ` Tom Tromey
2008-10-14 20:55 ` Pedro Alves [this message]
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=200810142155.10811.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=stanshebs@earthlink.net \
--cc=tromey@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