This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: breakpoint for accessing memory location


Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Sun, 22 Oct 2006 13:24:31 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sourceware.org
>> 
>> On Sun, Oct 22, 2006 at 10:20:02AM -0500, Rodney M. Bates wrote:
>> > If p is local to an inner block, but the compiler did the common thing of
>> > flattening p and all its cousins into one activation record for the 
>> > containing
>> > function, does the watchpoint really get deleted when execution leaves the
>> > block, or when the containing function returns?
>> 
>> When the debug info says it goes out of scope, or more specifically,
>> when GDB no longer knows where to find it.
>
> Don't we record the frame in the watchpoint structure?  If so, the
> watchpoint is deleted when its frame is popped off the stack.

Actually, that's still not the ideal behavior.  The language
specification defines what it means for a variable to be "in scope" at
a particular program location.  That's the definition GDB should use,
ideally.  Consider code like this:

int
foo (void)
{
  ...;
  {
    int b = 10;
    /* X */
    ...;
  }
  /* Y */
  ...;
}

If I set a watchpoint on b at '/* X */', then that watchpoint should
be deleted at soon as we leave the local block in which it is
defined.  For example, if we step to '/* Y */', then the watchpoint
should be deleted, because the variables it refers to are no longer in
scope at that point.

Unfortunately, GDB doesn't do this.  Instead, it behaves just as Eli
said it does, and waits for the frame to be popped before removing the
watchpoint.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]