Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: Eli Zaretskii <eliz@elta.co.il>
Cc: gdb@sources.redhat.com
Subject: Re: Multiple locations vs. watchpoints.
Date: Thu, 30 Oct 2003 19:44:00 -0000	[thread overview]
Message-ID: <20031030194411.GA2786@nevyn.them.org> (raw)
In-Reply-To: <uk76njldz.fsf@elta.co.il>

On Thu, Oct 30, 2003 at 08:21:44AM +0200, Eli Zaretskii wrote:
> > Date: Thu, 30 Oct 2003 00:53:45 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Suppose we have this:
> > foo.c:static int *bar;
> > 
> > (gdb) watch *bar
> > 
> > My idea has sort of been to create a watchpoint with multiple locations, one
> > for bar and one for *bar, each representing a conceptual hardware watchpoint
> > (though not necessarily one hardware watchpoint resource).
> 
> Yes, we do it now, albeit differently at the high level.
> 
> > And for this:
> > foo.c:static int foo()
> > bar.c:static int foo()
> > 
> > (gdb) break foo
> > 
> > My idea has sort of been that we should have a breakpoint with two
> > bp_locations, one for foo.c:foo and one for bar.c:foo.
> 
> I don't think we should do that.  I think we should leave things as
> they are now, namely, that "break foo" means the function foo in the
> _current_ module, be that foo.c or bar.c.  For the other, the user is
> required to type "break bar.c:foo".
> 
> In C++ and other OO languages, this is different, but in C we
> shouldn't introduce confusion, IMHO.  Someone who debugs a C program
> doesn't expect to get a breakpoint on a completely different function.

And when neither of these functions is in the "current" file (I hate
transparent state like that)?

We tend to get one at random.  This kills me once in a while when
working on BFD.
> > But suppose we have this:
> > foo.c:static int *bar;
> > bar.c:static int *bar;
> > 
> > (gdb) watch *bar
> > 
> > 
> > It watches whatever *bar would print, which is one of them.  No easy way to
> > get at the other or describe the ambiguity.  I wonder once again whether the
> > two-level scheme is really correctly designed; but I have no better ideas.
> 
> Accept my position about static functions in C, and this problem goes
> away.
> 
> But if you still want to put a watchpoint on both static variables,
> then there might be no reason for multi-level schemes: simply have the
> chain of addresses include foo.c:bar, foo.c:*bar, bar.c:bar, and
> bar.c:*bar.
> 
> Does this make sense?

Yes, I think so.

Hmm.  This suggests that I may be overloading one data structure for
two incompatible purposes.  I need to think about it a little.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


  parent reply	other threads:[~2003-10-30 19:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-30  5:53 Daniel Jacobowitz
2003-10-30  6:21 ` Eli Zaretskii
2003-10-30 19:40   ` Andrew Cagney
2003-10-30 19:44   ` Daniel Jacobowitz [this message]
2003-10-30 20:39     ` Eli Zaretskii
2003-10-30  6:25 ` Peter Barada

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=20031030194411.GA2786@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=eliz@elta.co.il \
    --cc=gdb@sources.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