From: Pedro Alves <pedro@codesourcery.com>
To: Stan Shebs <stanshebs@earthlink.net>
Cc: gdb-patches@sourceware.org
Subject: Re: PATCH: Remove dead code, clear breakpoint ignore counts?
Date: Tue, 14 Oct 2008 18:53:00 -0000 [thread overview]
Message-ID: <200810141952.58714.pedro@codesourcery.com> (raw)
In-Reply-To: <48F4E5A0.6010602@earthlink.net>
On Tuesday 14 October 2008 19:32:00, Stan Shebs wrote:
> Pedro Alves wrote:
> > I think I stared at this one time too many.
> >
> > What do you think of the attached? Would anyone miss this? There's
> > no way the user can request to not show hit counts, so, this is dead
> > code.
> >
> Heh, I can't even remember why it seemed like there was any interest in
> conditionalizing; perhaps because the hit counts were a new feature and
> we thought users would want to be able to go back to the old behavior.
> In any case, I think by now there is consensus that hit counts are good
> to display. :-)
Seems like it. :-) I guess I wasn't that clear, but the actual code
that initialy bothered me was the clearing the *ignore* counts in
generic_mourn_inferior, or better, the comment there that I must have read a
hundred times already by now, although it's dead code.
Just curious, do people think that it's useful to clear the hit
count automatically at all, considering that we do it on "run" but not
on "attach" or "target remote"? I can't seem to make up my mind
on it. It's still logicaly the same breakpoint across runs, so it
could make sense to not do so.
>
> Hit counts are going to get a little messy for multi-process, because
> each inferior could have a different hit count, and it seems more useful
> to have a per-inferior hit count than an aggregate over all the
> inferiors to which the breakpoint applies.
>
Right, that would mean storing a hit count per-breakpoint location as well
as per-breakpoint, it seems. Same for ignore counts. I'm sure there's
a user out there who would find that useful for breakpoints with multiple
locations in the single-inferior case too. :-)
--
Pedro Alves
next prev parent reply other threads:[~2008-10-14 18:53 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 [this message]
2008-10-14 20:10 ` Tom Tromey
2008-10-14 20:55 ` Pedro Alves
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=200810141952.58714.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
--cc=stanshebs@earthlink.net \
/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