Multiple locations vs. watchpoints.

Multiple locations vs. watchpoints.

[Daniel Jacobowitz]

Just something I was thinking about while writing my last message...

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


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.


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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Multiple locations vs. watchpoints.

[Eli Zaretskii]

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

Re: Multiple locations vs. watchpoints.

[Peter Barada]

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

You should be able to specify 'watch func::*bar' where func is the name of a
function that has scope on the *bar you are interested in.

I haven't tried this myself, but 'p/x func::foo' is something I've
done too many times to count so reason leads me to believe that the
watch command should use the same evaluator, right?

-- 
Peter Barada
peter@baradas.org

Re: Multiple locations vs. watchpoints.

[Andrew Cagney]

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

Yes, it also applies to OO languages.  The current SAL, frame, ... 
specify the scope that is used to qualify the breakpoint / watchpoint.

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

I think there are two largely independant problems here:

- two level breakpoint / location table
this assumes that something like "rbreak <pattern>" just creates 
multiple breakpoints (which are then broken down into locations)

- CLI operations and changes that provide greater flexability in 
manipulating the breakpoint table (rdelete, renable, breakpoint groups, 
...?)

and personally I'd be completly ignoring the second one for the moment.

enjoy,
Andrew

Re: Multiple locations vs. watchpoints.

[Daniel Jacobowitz]

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

Re: Multiple locations vs. watchpoints.

[Eli Zaretskii]

> Date: Thu, 30 Oct 2003 14:44:11 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> And when neither of these functions is in the "current" file

I guess in that case we should ask the user which one does she mean.

> We tend to get one at random.

That sounds like a bug (from the user point of view).