Re: Multiple locations vs. watchpoints.

[Eli Zaretskii <eliz at elta dot co dot il>]

> 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.

> 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?