Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


      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