breakpoint for accessing memory location

breakpoint for accessing memory location

[Erik Leunissen]

Hi,

I've got a shared lib that I programmed to store some data on the heap 
in order to retrieve them later. The main program which loads the shared 
lib appears to overwrite that location in memory, before the next time I 
want to use it (which is weird because the main program shouldn't have a 
clue about this particular action of the shared lib).

So, in order to find out which part of the main program is being nasty, 
I want to set some kind of breakpoint that alerts me whenever that 
memory location is being written to.

Is that possible using gdb?


(P.S. In the manual, I found the gdb command [break *address], but from 
its behaviour, I think it's meant to do something different from what I 
want.)


Thanks for any help,

Erik Leunissen

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Thu, Oct 19, 2006 at 10:10:46PM +0200, Erik Leunissen wrote:
> Hi,
> 
> I've got a shared lib that I programmed to store some data on the heap 
> in order to retrieve them later. The main program which loads the shared 
> lib appears to overwrite that location in memory, before the next time I 
> want to use it (which is weird because the main program shouldn't have a 
> clue about this particular action of the shared lib).
> 
> So, in order to find out which part of the main program is being nasty, 
> I want to set some kind of breakpoint that alerts me whenever that 
> memory location is being written to.
> 
> Is that possible using gdb?
> 
> 
> (P.S. In the manual, I found the gdb command [break *address], but from 
> its behaviour, I think it's meant to do something different from what I 
> want.)

Take a look at "watchpoints" in the manual.  They should be exactly
what you need.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Erik Leunissen]

Daniel Jacobowitz wrote:
> 
> Take a look at "watchpoints" in the manual.  They should be exactly
> what you need.
> 

Yes, I saw watchpoints also, but didn't recognize them as being useful 
in my case. From the manual:

watch expr
     Set a watchpoint for an expression. GDB will break when expr is
     written into by the program and its value changes.

Did you mean that "expr" may stand for a specific memory location?

(In my case, assuming that the memory location that I want to watch is 
0x08135400, I could simply do

     watch 0x08135400   ?)



Thanks,

Erik

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Thu, Oct 19, 2006 at 10:23:56PM +0200, Erik Leunissen wrote:
> Daniel Jacobowitz wrote:
> >
> >Take a look at "watchpoints" in the manual.  They should be exactly
> >what you need.
> >
> 
> Yes, I saw watchpoints also, but didn't recognize them as being useful 
> in my case. From the manual:
> 
> watch expr
>     Set a watchpoint for an expression. GDB will break when expr is
>     written into by the program and its value changes.
> 
> Did you mean that "expr" may stand for a specific memory location?
> 
> (In my case, assuming that the memory location that I want to watch is 
> 0x08135400, I could simply do
> 
>     watch 0x08135400   ?)

Almost, but not quite.  "0x08135400" is an expression whose value never
changes.  But "*(int*)0x08135400" is an expression that will change
when that memory location is written to.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Erik Leunissen]

Daniel Jacobowitz wrote:
> 
> Almost, but not quite.  "0x08135400" is an expression whose value never
> changes.  But "*(int*)0x08135400" is an expression that will change
> when that memory location is written to.
> 

OK, understood.

Thanks very much for you prompt help,

Erik

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Thu, 19 Oct 2006 22:23:56 +0200
> From: Erik Leunissen <e.leunissen@hccnet.nl>
> 
> Daniel Jacobowitz wrote:
> > 
> > Take a look at "watchpoints" in the manual.  They should be exactly
> > what you need.
> 
> Yes, I saw watchpoints also, but didn't recognize them as being useful 
> in my case. From the manual:
> 
> watch expr
>      Set a watchpoint for an expression. GDB will break when expr is
>      written into by the program and its value changes.

The beginning of that section has a better explanation:

    You can use a watchpoint to stop execution whenever the value of an
    expression changes, without having to predict a particular place where
    this may happen.

What text would you suggest to have there that would have helped you
recognize that this is the feature you wanted?  If you were looking
for some specific words or phrases, please tell what they are.  This
will allow us to improve the manual.

TIA

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Fri, Oct 20, 2006 at 08:31:32AM +0200, Eli Zaretskii wrote:
> What text would you suggest to have there that would have helped you
> recognize that this is the feature you wanted?  If you were looking
> for some specific words or phrases, please tell what they are.  This
> will allow us to improve the manual.

A lot of other toolchains call this a "data breakpoint", but the only
reference to that term in our manual is not very helpful.  Maybe that
would help.

-- 
Daniel Jacobowitz
CodeSourcery

[commit] Fix annotations-related index entries (was: breakpoint for accessing memory location)

[Eli Zaretskii]

While working on clarifying the watchpoints documentation, I found
that the index entries for annotations are too general, and get in the
way when one looks for the description of the topic, rather than the
annotations for that topic.  For example, the index entry "watchpoint"
pointed to the description of the "^Z^Zwatchpoint N" annotation(!).
It is highly unlikely that people who type "i watchpoint" in Info
would expect to land in the description of watchpoint-related
annotations.

So I modified the index entries for annotations-related issues to
include the word "annotation" explicitly; see the patch below.

The general rule is: never write a general index entry for a
specialized topic.  Always make sure such specialized index entries
are qualified with a reference to their parent feature (in this case,
"annotations").

Committed.

2006-10-21  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Source Annotations): Fix index entries by
	adding "annotation" to them, to discriminate from index
	entries that point to the more general topic descriptions.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.364
retrieving revision 1.365
diff -u -r1.364 -r1.365
--- gdb.texinfo	21 Oct 2006 12:54:18 -0000	1.364
+++ gdb.texinfo	21 Oct 2006 13:06:03 -0000	1.365
@@ -21529,34 +21529,34 @@
 The input types are
 
 @table @code
-@findex pre-prompt
-@findex prompt
-@findex post-prompt
+@findex pre-prompt annotation
+@findex prompt annotation
+@findex post-prompt annotation
 @item prompt
 When @value{GDBN} is prompting for a command (the main @value{GDBN} prompt).
 
-@findex pre-commands
-@findex commands
-@findex post-commands
+@findex pre-commands annotation
+@findex commands annotation
+@findex post-commands annotation
 @item commands
 When @value{GDBN} prompts for a set of commands, like in the @code{commands}
 command.  The annotations are repeated for each command which is input.
 
-@findex pre-overload-choice
-@findex overload-choice
-@findex post-overload-choice
+@findex pre-overload-choice annotation
+@findex overload-choice annotation
+@findex post-overload-choice annotation
 @item overload-choice
 When @value{GDBN} wants the user to select between various overloaded functions.
 
-@findex pre-query
-@findex query
-@findex post-query
+@findex pre-query annotation
+@findex query annotation
+@findex post-query annotation
 @item query
 When @value{GDBN} wants the user to confirm a potentially dangerous operation.
 
-@findex pre-prompt-for-continue
-@findex prompt-for-continue
-@findex post-prompt-for-continue
+@findex pre-prompt-for-continue annotation
+@findex prompt-for-continue annotation
+@findex post-prompt-for-continue annotation
 @item prompt-for-continue
 When @value{GDBN} is asking the user to press return to continue.  Note: Don't
 expect this to work well; instead use @code{set height 0} to disable
@@ -21568,14 +21568,14 @@
 @section Errors
 @cindex annotations for errors, warnings and interrupts
 
-@findex quit
+@findex quit annotation
 @smallexample
 ^Z^Zquit
 @end smallexample
 
 This annotation occurs right before @value{GDBN} responds to an interrupt.
 
-@findex error
+@findex error annotation
 @smallexample
 ^Z^Zerror
 @end smallexample
@@ -21590,7 +21590,7 @@
 does not necessarily mean that @value{GDBN} is immediately returning all the way
 to the top level.
 
-@findex error-begin
+@findex error-begin annotation
 A quit or error annotation may be preceded by
 
 @smallexample
@@ -21612,13 +21612,13 @@
 changed.
 
 @table @code
-@findex frames-invalid
+@findex frames-invalid annotation
 @item ^Z^Zframes-invalid
 
 The frames (for example, output from the @code{backtrace} command) may
 have changed.
 
-@findex breakpoints-invalid
+@findex breakpoints-invalid annotation
 @item ^Z^Zbreakpoints-invalid
 
 The breakpoints may have changed.  For example, the user just added or
@@ -21629,8 +21629,8 @@
 @section Running the Program
 @cindex annotations for running programs
 
-@findex starting
-@findex stopping
+@findex starting annotation
+@findex stopping annotation
 When the program starts executing due to a @value{GDBN} command such as
 @code{step} or @code{continue},
 
@@ -21648,16 +21648,16 @@
 annotations describe how the program stopped.
 
 @table @code
-@findex exited
+@findex exited annotation
 @item ^Z^Zexited @var{exit-status}
 The program exited, and @var{exit-status} is the exit status (zero for
 successful exit, otherwise nonzero).
 
-@findex signalled
-@findex signal-name
-@findex signal-name-end
-@findex signal-string
-@findex signal-string-end
+@findex signalled annotation
+@findex signal-name annotation
+@findex signal-name-end annotation
+@findex signal-string annotation
+@findex signal-string-end annotation
 @item ^Z^Zsignalled
 The program exited with a signal.  After the @code{^Z^Zsignalled}, the
 annotation continues:
@@ -21681,17 +21681,17 @@
 @var{intro-text}, @var{middle-text}, and @var{end-text} are for the
 user's benefit and have no particular format.
 
-@findex signal
+@findex signal annotation
 @item ^Z^Zsignal
 The syntax of this annotation is just like @code{signalled}, but @value{GDBN} is
 just saying that the program received the signal, not that it was
 terminated with it.
 
-@findex breakpoint
+@findex breakpoint annotation
 @item ^Z^Zbreakpoint @var{number}
 The program hit breakpoint number @var{number}.
 
-@findex watchpoint
+@findex watchpoint annotation
 @item ^Z^Zwatchpoint @var{number}
 The program hit watchpoint number @var{number}.
 @end table
@@ -21700,7 +21700,7 @@
 @section Displaying Source
 @cindex annotations for source display
 
-@findex source
+@findex source annotation
 The following annotation is used instead of displaying source code:
 
 @smallexample

Re: breakpoint for accessing memory location

[Erik Leunissen]

Eli Zaretskii wrote:
> 
> What text would you suggest to have there that would have helped you
> recognize that this is the feature you wanted?  If you were looking
> for some specific words or phrases, please tell what they are.  This
> will allow us to improve the manual.
> 

OK, I was led off the track by the word "expr" without there being an 
explanation of its use, which may be quite powerful and encompass a 
diversity which the mere mentioning of the single word "expr" fails to 
express.

Below you find how I failed to see its usefulness and a beginning of a 
formulation that would have prevented me from missing it.


Actually I was prepared to find a feature like "setting a watch on 
something", which interrupts program execution as soon as the value for 
  "something" changes. So, the term watchpoint is not the problem (it is 
one of the things I tried in the first place).

The reasons for missing its usefulness are:
1. From previous experience (I believe I derive that from a Turbo Pascal 
IDE compiler/debugger) I knew a feature that sets a watchpoint on a 
*variable*. However, the manual mentions an "expr" to watch for. An 
"expr" is more abstract, but probably includes variables.

2. I tried to set a watch on the memory address of the variable that was 
giving me trouble (this appeared not to be very useful as Daniel pointed 
out, but that's beside the point now).
The reason I tried such a less useful thing also lies in the fact that 
"expr" can mean a lot, and one has to devise an interpretation for it 
oneself. The diversity of the possible interpretations of "expr" isn't 
worked out in a set of examples.

3. My experiment with a fixed memory address failed. That's when I 
reverted to breakpoints, which (of course) is not what I was looking for.

4. I sought help in this mailing list (thanks again).

So, to summarize a long story:

"expr" can mean a lot of different things, but programmers that are new 
to debugging, or new to gdb will not have much idea about useful 
interpretations of that term. If no words are spent on an explanation of 
the power of this single word then users may get lost.


As for a recommended formulation, well, something along the lines of:

watch expr
     Set a watchpoint for an expression. GDB will break when expr is
     written into by the program and its value changes. Be aware that 
expr is a powerful construct that can be used to:
     - indicate a variable: [include a reference to an example]
     - a value at a specific memory address (without a variable needing 
to reference it): [include a reference to an example]
     - other useful interpretations that I don't see right now ...

Please feel free to adapt from this suggestion, since it should be clear 
that I don't oversee the extent to which expr may be usefully 
interpreted in this case.

Sincerely,

Erik Leunissen

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Fri, 20 Oct 2006 18:55:57 +0200
> From: Erik Leunissen <e.leunissen@hccnet.nl>
> 
> "expr" can mean a lot of different things, but programmers that are new 
> to debugging, or new to gdb will not have much idea about useful 
> interpretations of that term. If no words are spent on an explanation of 
> the power of this single word then users may get lost.

Thanks, I will add some explanation to clear this up.

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Fri, 20 Oct 2006 18:55:57 +0200
> From: Erik Leunissen <e.leunissen@hccnet.nl>
> 
> So, to summarize a long story:
> 
> "expr" can mean a lot of different things, but programmers that are new 
> to debugging, or new to gdb will not have much idea about useful 
> interpretations of that term. If no words are spent on an explanation of 
> the power of this single word then users may get lost.

I fixed the manual as shown below.  Please see if this addresses your
concerns.

Daniel, I added a reference to the term "data breakpoints" as well,
thanks for the suggestion.

The patches below are committed.

2006-10-21  Eli Zaretskii  <eliz@gnu.org>

	* gdb.texinfo (Breakpoints, Set Watchpoints): Elaborate and
	clarify on the possible meanings of ``expression'' watched by
	watchpoints.  Add indexing.

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.362
retrieving revision 1.364
diff -u -r1.362 -r1.364
--- gdb.texinfo	21 Oct 2006 12:20:59 -0000	1.362
+++ gdb.texinfo	21 Oct 2006 12:50:16 -0000	1.364
@@ -2773,15 +2773,19 @@
 call).
 
 @cindex watchpoints
+@cindex data breakpoints
 @cindex memory tracing
 @cindex breakpoint on memory address
 @cindex breakpoint on variable modification
 A @dfn{watchpoint} is a special breakpoint that stops your program
-when the value of an expression changes.  You must use a different
-command to set watchpoints (@pxref{Set Watchpoints, ,Setting
-watchpoints}), but aside from that, you can manage a watchpoint like
-any other breakpoint: you enable, disable, and delete both breakpoints
-and watchpoints using the same commands.
+when the value of an expression changes.  The expression may be a value
+of a variable, or it could involve values of one or more variables
+combined by operators, such as @samp{a + b}.  This is sometimes called
+@dfn{data breakpoints}.  You must use a different command to set
+watchpoints (@pxref{Set Watchpoints, ,Setting watchpoints}), but aside
+from that, you can manage a watchpoint like any other breakpoint: you
+enable, disable, and delete both breakpoints and watchpoints using the
+same commands.
 
 You can arrange to have values from your program displayed automatically
 whenever @value{GDBN} stops at a breakpoint.  @xref{Auto Display,,
@@ -3106,7 +3110,24 @@
 @cindex setting watchpoints
 You can use a watchpoint to stop execution whenever the value of an
 expression changes, without having to predict a particular place where
-this may happen.
+this may happen.  (This is sometimes called a @dfn{data breakpoint}.)
+The expression may be as simple as the value of a single variable, or
+as complex as many variables combined by operators.  Examples include:
+
+@itemize @bullet
+@item
+A reference to the value of a single variable.
+
+@item
+An address cast to an appropriate data type.  For example,
+@samp{*(int *)0x12345678} will watch a 4-byte region at the specified
+address (assuming an @code{int} occupies 4 bytes).
+
+@item
+An arbitrarily complex expression, such as @samp{a*b + c/d}.  The
+expression can use any operators valid in the program's native
+language (@pxref{Languages}).
+@end itemize
 
 @cindex software watchpoints
 @cindex hardware watchpoints
@@ -3124,8 +3145,14 @@
 @table @code
 @kindex watch
 @item watch @var{expr}
-Set a watchpoint for an expression.  @value{GDBN} will break when @var{expr}
-is written into by the program and its value changes.
+Set a watchpoint for an expression.  @value{GDBN} will break when the
+expression @var{expr} is written into by the program and its value
+changes.  The simplest (and the most popular) use of this command is
+to watch the value of a single variable:
+
+@smallexample
+(@value{GDBP}) watch foo
+@end smallexample
 
 @kindex rwatch
 @item rwatch @var{expr}
@@ -3217,6 +3244,11 @@
 @noindent
 If this happens, delete or disable some of the watchpoints.
 
+Watching complex expressions that reference many variables can also
+exhaust the resources available for hardware-assisted watchpoints.
+That's because @value{GDBN} needs to watch every variable in the
+expression with separately allocated resources.
+
 The SPARClite DSU will generate traps when a program accesses some data
 or instruction address that is assigned to the debug registers.  For the
 data addresses, DSU facilitates the @code{watch} command.  However the

Re: breakpoint for accessing memory location

[Erik Leunissen]

Eli Zaretskii wrote:
> 
> I fixed the manual as shown below.  Please see if this addresses your
> concerns.
> 

It certainly does. See one nit below.

Thanks,

Erik Leunissen

>  A @dfn{watchpoint} is a special breakpoint that stops your program
> -when the value of an expression changes.  You must use a different
> -command to set watchpoints (@pxref{Set Watchpoints, ,Setting
> -watchpoints}), but aside from that, you can manage a watchpoint like
> -any other breakpoint: you enable, disable, and delete both breakpoints
> -and watchpoints using the same commands.
> +when the value of an expression changes.  The expression may be a value
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +of a variable, or it could involve values of one or more variables
    ^^^^^^^^^^^^^

We watch for a change in the value of the variable, OK. However the 
corresponding expression for that case simply holds the *name* of the 
variable, doesn't it?

> +combined by operators, such as @samp{a + b}.  This is sometimes called
> +@dfn{data breakpoints}.  You must use a different command to set
> +watchpoints (@pxref{Set Watchpoints, ,Setting watchpoints}), but aside
> +from that, you can manage a watchpoint like any other breakpoint: you
> +enable, disable, and delete both breakpoints and watchpoints using the
> +same commands.
>  
>  You can arrange to have values from your program displayed automatically
>  whenever @value{GDBN} stops at a breakpoint.  @xref{Auto Display,,
> @@ -3106,7 +3110,24 @@
>  @cindex setting watchpoints
>  You can use a watchpoint to stop execution whenever the value of an
>  expression changes, without having to predict a particular place where
> -this may happen.
> +this may happen.  (This is sometimes called a @dfn{data breakpoint}.)
> +The expression may be as simple as the value of a single variable, or
                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                       same here

> +as complex as many variables combined by operators.  Examples include:
> +
> +@itemize @bullet
> +@item
> +A reference to the value of a single variable.
> +
> +@item
> +An address cast to an appropriate data type.  For example,
> +@samp{*(int *)0x12345678} will watch a 4-byte region at the specified
> +address (assuming an @code{int} occupies 4 bytes).
> +
> +@item
> +An arbitrarily complex expression, such as @samp{a*b + c/d}.  The
> +expression can use any operators valid in the program's native
> +language (@pxref{Languages}).
> +@end itemize
>  
>  @cindex software watchpoints
>  @cindex hardware watchpoints
> @@ -3124,8 +3145,14 @@
>  @table @code
>  @kindex watch
>  @item watch @var{expr}
> -Set a watchpoint for an expression.  @value{GDBN} will break when @var{expr}
> -is written into by the program and its value changes.
> +Set a watchpoint for an expression.  @value{GDBN} will break when the
> +expression @var{expr} is written into by the program and its value
> +changes.  The simplest (and the most popular) use of this command is
> +to watch the value of a single variable:
> +
> +@smallexample
> +(@value{GDBP}) watch foo
> +@end smallexample
>  
>  @kindex rwatch
>  @item rwatch @var{expr}
> @@ -3217,6 +3244,11 @@
>  @noindent
>  If this happens, delete or disable some of the watchpoints.
>  
> +Watching complex expressions that reference many variables can also
> +exhaust the resources available for hardware-assisted watchpoints.
> +That's because @value{GDBN} needs to watch every variable in the
> +expression with separately allocated resources.
> +
>  The SPARClite DSU will generate traps when a program accesses some data
>  or instruction address that is assigned to the debug registers.  For the
>  data addresses, DSU facilitates the @code{watch} command.  However the
> 
> 

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 00:27:48 +0200
> From: Erik Leunissen <e.leunissen@hccnet.nl>
> CC: gdb@sourceware.org
> > +when the value of an expression changes.  The expression may be a value
>                                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +of a variable, or it could involve values of one or more variables
>     ^^^^^^^^^^^^^
> 
> We watch for a change in the value of the variable, OK. However the 
> corresponding expression for that case simply holds the *name* of the 
> variable, doesn't it?

Well, yes, but how far should we go in explaining the semantics of
programming languages?  I mean, isn't it common knowledge that the
name of a variable stands for its value?  When the manual says ``the
value of a variable'', what could the reader possibly think of except
the variable's name?

Re: breakpoint for accessing memory location

[Erik Leunissen]

Eli Zaretskii wrote:
> 
> Well, yes, but how far should we go in explaining the semantics of
> programming languages?  I mean, isn't it common knowledge that the
> name of a variable stands for its value?  When the manual says ``the
> value of a variable'', what could the reader possibly think of except
> the variable's name?
> 

True, if C is the sole perspective. If so please disregard.

My remark stems from experience with dynamic programming languages. In 
that area, separate methods exist to programmatically refer to the name 
of a variable and to its value (Tcl example appended).

So, it depends on your background I suppose. And mine may be odd. Also, 
it may be ineffective to consider from where people may enter the 
debugging arena (or C arena). I leave this entirely to your judgement.

Regardless, I'm already very pleased with the explanation as it is now.

Thanks,

Erik
====

Interactive Tcl example (I guess Python and Perl show similar behaviour):

% set variableName 34
34
% puts $variableName
34
% puts variableName
variableName

== end of post ==

Re: breakpoint for accessing memory location

[Erik Leunissen]

Erik Leunissen wrote:
> 
> Interactive Tcl example (I guess Python and Perl show similar behaviour):
> 
> % set variableName 34
> 34
> % puts $variableName
> 34
> % puts variableName
> variableName
> 

A better example is:

% set varName thisVar
thisVar
% set thisVar 34
34
% set $varName
34

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 11:11:04 +0200
> From: Erik Leunissen <e.leunissen@hccnet.nl>
> 
> Eli Zaretskii wrote:
> > 
> > Well, yes, but how far should we go in explaining the semantics of
> > programming languages?  I mean, isn't it common knowledge that the
> > name of a variable stands for its value?  When the manual says ``the
> > value of a variable'', what could the reader possibly think of except
> > the variable's name?
> > 
> 
> True, if C is the sole perspective. If so please disregard.

No, I meant any programming language supported by GDB.  Are there any
that don't behave like described above?

> So, it depends on your background I suppose.

My background includes a few languages that behave differently, but
AFAIK none of them is supported by GDB.

Re: breakpoint for accessing memory location

[Erik Leunissen]

Eli Zaretskii wrote:
> 
> No, I meant any programming language supported by GDB.  Are there any
> that don't behave like described above?
> 
>> So, it depends on your background I suppose.

I was unclear here. I meant that to be:

"So, it depends on ones background I suppose."
                    ^^^^

    not referring to your particular background, Eli.

> 
> My background includes a few languages that behave differently, but
> AFAIK none of them is supported by GDB.
> 

I have no overview over languages supported by gdb. Therefore, I 
consider your insight authoritative.

Cheers,

Erik.

Re: breakpoint for accessing memory location

[Rodney M. Bates]

Eli Zaretskii wrote:
> The beginning of that section has a better explanation:
> 
>     You can use a watchpoint to stop execution whenever the value of an
>     expression changes, without having to predict a particular place where
>     this may happen.
> 
> What text would you suggest to have there that would have helped you
> recognize that this is the feature you wanted?  If you were looking
> for some specific words or phrases, please tell what they are.  This
> will allow us to improve the manual.
> 
> TIA
> 

I have never had trouble understanding this sentence, although I have
thought "a particular place in the code" would be even clearer.

But while this subject is open, I would like to see more explanation on just
what the semantics of evaluating a watchpoint expression are.  An expression
always is evaluated in a particular context that can affect the legality/result,
but in the case of a watchpoint, execution is proceeding and changing the
context.  I have never been sure what the rules are.

For example, I sometimes want to watch p->f, where p is local variable that
I know perfectly well will soon cease to exist, but I also know *p will
remain.  I've long since learned that watching p->f doesn't work.  Instead,
I print the address of p->f and then watch the contents of that address.

But more information on the general rules would be helpful in the manual.

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Sat, Oct 21, 2006 at 10:06:00AM -0500, Rodney M. Bates wrote:
> For example, I sometimes want to watch p->f, where p is local variable that
> I know perfectly well will soon cease to exist, but I also know *p will
> remain.  I've long since learned that watching p->f doesn't work.  Instead,
> I print the address of p->f and then watch the contents of that address.

Yes, this does seem to be a frequent point of confusion...

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sat, 21 Oct 2006 10:06:00 -0500
> From: "Rodney M. Bates" <rodney.bates@wichita.edu>
> CC:  gdb@sourceware.org
> 
> But while this subject is open, I would like to see more explanation on just
> what the semantics of evaluating a watchpoint expression are.  An expression
> always is evaluated in a particular context that can affect the legality/result,
> but in the case of a watchpoint, execution is proceeding and changing the
> context.  I have never been sure what the rules are.
> For example, I sometimes want to watch p->f, where p is local variable that
> I know perfectly well will soon cease to exist, but I also know *p will
> remain.  I've long since learned that watching p->f doesn't work.  Instead,
> I print the address of p->f and then watch the contents of that address.

Does "watch *(<type-of-p->f> *)&p->f" work as well?

> But more information on the general rules would be helpful in the manual.

Are there any more examples beyond p->f?  That is, what other
situations are there where the context can matter?  Are we talking
only about portions of expression going out of context (and thus
becoming invalid), or are there other problems?

(You see, I don't think I understand what you mean by ``the semantics
of evaluating a watchpoint expression'', and a single example you gave
is not enough for me to figure that out.)

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Sat, Oct 21, 2006 at 05:29:11PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 21 Oct 2006 10:06:00 -0500
> > From: "Rodney M. Bates" <rodney.bates@wichita.edu>
> > CC:  gdb@sourceware.org
> > 
> > But while this subject is open, I would like to see more explanation on just
> > what the semantics of evaluating a watchpoint expression are.  An expression
> > always is evaluated in a particular context that can affect the legality/result,
> > but in the case of a watchpoint, execution is proceeding and changing the
> > context.  I have never been sure what the rules are.
> > For example, I sometimes want to watch p->f, where p is local variable that
> > I know perfectly well will soon cease to exist, but I also know *p will
> > remain.  I've long since learned that watching p->f doesn't work.  Instead,
> > I print the address of p->f and then watch the contents of that address.
> 
> Does "watch *(<type-of-p->f> *)&p->f" work as well?

I'm pretty sure it won't.  Because "p" is still in the expression, we
consider the expression dependent on the value of p, so it goes out of
scope when p does.

I use:
  p &p->f
  watch *$

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sat, 21 Oct 2006 11:51:25 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: "Rodney M. Bates" <rodney.bates@wichita.edu>, gdb@sourceware.org
> 
> > > I print the address of p->f and then watch the contents of that address.
> > 
> > Does "watch *(<type-of-p->f> *)&p->f" work as well?
> 
> I'm pretty sure it won't.  Because "p" is still in the expression, we
> consider the expression dependent on the value of p, so it goes out of
> scope when p does.

So you are saying that "watch p - p" will also cause an error message
when p goes out of scope?

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Sat, Oct 21, 2006 at 11:26:10PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 21 Oct 2006 11:51:25 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: "Rodney M. Bates" <rodney.bates@wichita.edu>, gdb@sourceware.org
> > 
> > > > I print the address of p->f and then watch the contents of that address.
> > > 
> > > Does "watch *(<type-of-p->f> *)&p->f" work as well?
> > 
> > I'm pretty sure it won't.  Because "p" is still in the expression, we
> > consider the expression dependent on the value of p, so it goes out of
> > scope when p does.
> 
> So you are saying that "watch p - p" will also cause an error message
> when p goes out of scope?

Well, I just tried it; that's what I'd expect, and it seems to be what
happens, also.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sat, 21 Oct 2006 18:32:00 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: rodney.bates@wichita.edu, gdb@sourceware.org
> > 
> > So you are saying that "watch p - p" will also cause an error message
> > when p goes out of scope?
> 
> Well, I just tried it; that's what I'd expect, and it seems to be what
> happens, also.

That's silly, IMHO.  Don't you think we should be smarter?  Perhaps
some kind of expression optimizer could be devised to do better.

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Sun, Oct 22, 2006 at 06:17:58AM +0200, Eli Zaretskii wrote:
> > Date: Sat, 21 Oct 2006 18:32:00 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: rodney.bates@wichita.edu, gdb@sourceware.org
> > > 
> > > So you are saying that "watch p - p" will also cause an error message
> > > when p goes out of scope?
> > 
> > Well, I just tried it; that's what I'd expect, and it seems to be what
> > happens, also.
> 
> That's silly, IMHO.  Don't you think we should be smarter?  Perhaps
> some kind of expression optimizer could be devised to do better.

I really don't think we should be optimizing expressions.  One
certainly could be devised - but it would look like "fold" in GCC,
which is a huge and horrendously complex thing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Robert Dewar]

Daniel Jacobowitz wrote:

> I really don't think we should be optimizing expressions.  One
> certainly could be devised - but it would look like "fold" in GCC,
> which is a huge and horrendously complex thing.

And it would lead to surprising results, if you watch p-p and p is
out of scope, it would be surprising if it did NOT lead to an error!
> 

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 08:18:53 -0400
> From: Robert Dewar <dewar@adacore.com>
> 
> And it would lead to surprising results, if you watch p-p and p is
> out of scope, it would be surprising if it did NOT lead to an error!

Strange, I'd actually expect GDB to tell me that "watch p-p" is an
invalid command.  Something like

   Warning: attempt to watch constant expression.

I guess we have very different notions of what is reasonable in this
context.

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Mon, Oct 23, 2006 at 12:18:50AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Oct 2006 08:18:53 -0400
> > From: Robert Dewar <dewar@adacore.com>
> > 
> > And it would lead to surprising results, if you watch p-p and p is
> > out of scope, it would be surprising if it did NOT lead to an error!
> 
> Strange, I'd actually expect GDB to tell me that "watch p-p" is an
> invalid command.  Something like
> 
>    Warning: attempt to watch constant expression.

I think that would be a useful warning, but that we shouldn't go to the
trouble of making it catch things like "p-p" where you would need an
optimizer to figure it out.

Telling the user that watching "0x8000" doesn't do what they expect
would be a nice improvement though!

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 18:21:43 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Robert Dewar <dewar@adacore.com>, rodney.bates@wichita.edu,
> 	gdb@sourceware.org
> 
> >    Warning: attempt to watch constant expression.
> 
> I think that would be a useful warning, but that we shouldn't go to the
> trouble of making it catch things like "p-p" where you would need an
> optimizer to figure it out.

Trouble? what trouble?  Just sample the value of the expression for
several random values of the variables, and if the value doesn't
change, consider it constant.

> Telling the user that watching "0x8000" doesn't do what they expect
> would be a nice improvement though!

Yep.

Re: breakpoint for accessing memory location

[Robert Dewar]

Eli Zaretskii wrote:

> Trouble? what trouble?  Just sample the value of the expression for
> several random values of the variables, and if the value doesn't
> change, consider it constant.

Well I think I will save this as an ultimate example of vague
semantics :-)

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Mon, Oct 23, 2006 at 12:28:57AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Oct 2006 18:21:43 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Robert Dewar <dewar@adacore.com>, rodney.bates@wichita.edu,
> > 	gdb@sourceware.org
> > 
> > >    Warning: attempt to watch constant expression.
> > 
> > I think that would be a useful warning, but that we shouldn't go to the
> > trouble of making it catch things like "p-p" where you would need an
> > optimizer to figure it out.
> 
> Trouble? what trouble?  Just sample the value of the expression for
> several random values of the variables, and if the value doesn't
> change, consider it constant.

Was this sarcasm?  If not, please consider "watch p != 42" for a couple
of random values of p.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Robert Dewar]

Daniel Jacobowitz wrote:
>
>> Trouble? what trouble?  Just sample the value of the expression for
>> several random values of the variables, and if the value doesn't
>> change, consider it constant.
> 
> Was this sarcasm?  If not, please consider "watch p != 42" for a couple
> of random values of p.

I suspect it was not sarcasm, just an ill-thought out proposal,
but your counter-example is VERY nice indeed!

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 19:18:47 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: dewar@adacore.com, rodney.bates@wichita.edu, gdb@sourceware.org
> 
> > Trouble? what trouble?  Just sample the value of the expression for
> > several random values of the variables, and if the value doesn't
> > change, consider it constant.
> 
> Was this sarcasm?  If not, please consider "watch p != 42" for a couple
> of random values of p.

If that couple includes 42, then all is okay.

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Mon, Oct 23, 2006 at 06:11:52AM +0200, Eli Zaretskii wrote:
> > Date: Sun, 22 Oct 2006 19:18:47 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: dewar@adacore.com, rodney.bates@wichita.edu, gdb@sourceware.org
> > 
> > > Trouble? what trouble?  Just sample the value of the expression for
> > > several random values of the variables, and if the value doesn't
> > > change, consider it constant.
> > 
> > Was this sarcasm?  If not, please consider "watch p != 42" for a couple
> > of random values of p.
> 
> If that couple includes 42, then all is okay.

What are you trying to get at here?  Please don't suggest that we
should obviously try 42 because it appears in the source expression;
there are plenty of other examples where that is insufficient.  I think
such a warning would be extremely ill-considered, since it is
computationally infeasible for us to work out which expressions are
constant and which are just rare. Lots of the things people want to
watch will be rarely changing.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Robert Dewar]

Eli Zaretskii wrote:
>> Date: Sun, 22 Oct 2006 08:18:53 -0400
>> From: Robert Dewar <dewar@adacore.com>
>>
>> And it would lead to surprising results, if you watch p-p and p is
>> out of scope, it would be surprising if it did NOT lead to an error!
> 
> Strange, I'd actually expect GDB to tell me that "watch p-p" is an
> invalid command.  Something like
> 
>    Warning: attempt to watch constant expression.
> 
> I guess we have very different notions of what is reasonable in this
> context.

indeed!

I have no idea why you would think this is invalid, i.e. what the
general semantic rule is that makes this expression invalid.

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 18:48:34 -0400
> From: Robert Dewar <dewar@adacore.com>
> CC:  rodney.bates@wichita.edu,  gdb@sourceware.org
> 
> I have no idea why you would think this is invalid, i.e. what the
> general semantic rule is that makes this expression invalid.

The general rule is that watching a constant expression is silly,
since its value never changes and thus the watchpoint will never
break.  Thus, it's probably not what the user wanted, and a warning
would be a Good Thing, IMO.

Re: breakpoint for accessing memory location

[Robert Dewar]

Eli Zaretskii wrote:

> The general rule is that watching a constant expression is silly,
> since its value never changes and thus the watchpoint will never
> break.  Thus, it's probably not what the user wanted, and a warning
> would be a Good Thing, IMO.

Right, but of course it is recursively undecidable whether an
expression is constant, so you don't really mean what you say.
What you mean is that warnings could be given in a few cases,
e.g. where the expression is a literal, but going beyond this is a
waste of time, which will not be helpful in practice, no one
is going to watch p-p anyway.

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sun, 22 Oct 2006 18:55:46 -0400
> From: Robert Dewar <dewar@adacore.com>
> CC:  rodney.bates@wichita.edu,  gdb@sourceware.org
> 
> Eli Zaretskii wrote:
> 
> > The general rule is that watching a constant expression is silly,
> > since its value never changes and thus the watchpoint will never
> > break.  Thus, it's probably not what the user wanted, and a warning
> > would be a Good Thing, IMO.
> 
> Right, but of course it is recursively undecidable whether an
> expression is constant, so you don't really mean what you say.

No, I did mean what I said.  You asked about a principle, not about
the feasibility of its application.  Or at least that's what I thought
you were asking.

Re: breakpoint for accessing memory location

[Mark Kettenis]

> Date: Sun, 22 Oct 2006 00:22:30 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sun, Oct 22, 2006 at 06:17:58AM +0200, Eli Zaretskii wrote:
> > > Date: Sat, 21 Oct 2006 18:32:00 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > Cc: rodney.bates@wichita.edu, gdb@sourceware.org
> > > > 
> > > > So you are saying that "watch p - p" will also cause an error message
> > > > when p goes out of scope?
> > > 
> > > Well, I just tried it; that's what I'd expect, and it seems to be what
> > > happens, also.
> > 
> > That's silly, IMHO.  Don't you think we should be smarter?  Perhaps
> > some kind of expression optimizer could be devised to do better.
> 
> I really don't think we should be optimizing expressions.  One
> certainly could be devised - but it would look like "fold" in GCC,
> which is a huge and horrendously complex thing.

Agreed.

Re: breakpoint for accessing memory location

[Rodney M. Bates]

Eli Zaretskii wrote:
>> 
> Are there any more examples beyond p->f?  That is, what other
> situations are there where the context can matter?  Are we talking
> only about portions of expression going out of context (and thus
> becoming invalid), or are there other problems?
> 
> (You see, I don't think I understand what you mean by ``the semantics
> of evaluating a watchpoint expression'', and a single example you gave
> is not enough for me to figure that out.)
> 

Well, an expression in a program is always interpreted by looking up
any unqualified identifiers according to the scope rules, at the place in the
code where the expression appears.  But with a watchpoint, that place keeps
changing.  p can go out of scope, come back in, or a different p could become
visible.  So more example questions (same expression, different contexts):

If execution gets to where there is no p visible, does the watch get
permanently disabled?  Does execution stop?  Does the watch just get ignored
for now.  If execution comes back into the original scope, does the
expression start getting watched again?

If execution goes somewhere where a different p is visible, does the
watch get disabled?  temporarily ignored?  Is the expression reevaluated
using the new p?  What if this is type-incorrect (e.g. p is not a pointer, or
points to something that doesn't have an f)?  What if a different p points
to the same struct type or a different struct type that also has an f,
and the second f is the same type as the first, or a different type?

What if p is a variable in the original context but a type name in a later
context?  (Maybe there are no expressions that would be legal both ways?)

If the expression is illegal at the place where the program is stopped
when the watch is typed, is it rejected then and there, or kept around
in case, e.g., a p comes into scope.

I realize that the answer to one of my first questions could make the rest
of them irrelevant.  And I presume that just a change in the value of the
same p, while it remains in scope, means the watch now looks for changes to
the f of the new struct p points to, but even this might be worth explaining
explicitly.

As for different expressions, the only thing I think of that could matter
is each occurrence of an unqualified identifier, and these would all presumably
be independent.

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sat, 21 Oct 2006 13:07:01 -0500
> From: "Rodney M. Bates" <rodney.bates@wichita.edu>
> CC:  gdb@sourceware.org
> 
> Well, an expression in a program is always interpreted by looking up
> any unqualified identifiers according to the scope rules, at the place in the
> code where the expression appears.  But with a watchpoint, that place keeps
> changing.  p can go out of scope, come back in, or a different p could become
> visible.

The manual says:

       GDB automatically deletes watchpoints that watch local (automatic)
    variables, or expressions that involve such variables, when they go out
    of scope, that is, when the execution leaves the block in which these
    variables were defined.

> So more example questions (same expression, different contexts):

Given the above text, are the answers to any of your questions still
unclear?  If so, please tell what is still unclear, and why.

> If the expression is illegal at the place where the program is stopped
> when the watch is typed, is it rejected then and there, or kept around
> in case, e.g., a p comes into scope.

The expression is rejected right there and then.  GDB needs to find
the address of each variable that is part of the expression, and if it
cannot, it refuses to set the watchpoint.

Re: breakpoint for accessing memory location

[Rodney M. Bates]

> Are there any more examples beyond p->f?  That is, what other
> situations are there where the context can matter?  Are we talking
> only about portions of expression going out of context (and thus
> becoming invalid), or are there other problems?

Here are some more example questions, perhaps not quite so far fetched.

What if I put a watch on p->f where there is a visible p, then execution
goes somewhere where p is not visible, but p still exists?  For example,
suppose p is local to function foo, and foo calls non-nested function bar.

Or, I haven't placed the watch yet and first stop execution in bar.  Can
I now place this watch after moving up the stack to foo's frame?

In fact, in general, many of my questions about p's being visible could
be reformulated to p's existence, which might be a more meaningful
property.
-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Sat, 21 Oct 2006 13:55:25 -0500
> From: "Rodney M. Bates" <rodney.bates@wichita.edu>
> CC:  gdb@sourceware.org
> 
> What if I put a watch on p->f where there is a visible p, then execution
> goes somewhere where p is not visible, but p still exists?  For example,
> suppose p is local to function foo, and foo calls non-nested function bar.

This doesn't qualify as going out of scope, because p is still on the
stack.  Only when the function where p is declared returns, will p go
out of scope and the watchpoint be deleted.

> Or, I haven't placed the watch yet and first stop execution in bar.  Can
> I now place this watch after moving up the stack to foo's frame?

Yes, because p is in scope in any function called from foo.

Re: breakpoint for accessing memory location

[Rodney M. Bates]

Eli Zaretskii wrote:
>>Date: Sat, 21 Oct 2006 13:55:25 -0500
>>From: "Rodney M. Bates" <rodney.bates@wichita.edu>
>>CC:  gdb@sourceware.org
>>
>>What if I put a watch on p->f where there is a visible p, then execution
>>goes somewhere where p is not visible, but p still exists?  For example,
>>suppose p is local to function foo, and foo calls non-nested function bar.
> 
> 
> This doesn't qualify as going out of scope, because p is still on the
> stack.  Only when the function where p is declared returns, will p go
> out of scope and the watchpoint be deleted.
> 
> 
>>Or, I haven't placed the watch yet and first stop execution in bar.  Can
>>I now place this watch after moving up the stack to foo's frame?
> 
> 
> Yes, because p is in scope in any function called from foo.

Ah, so "goes out of scope" means means "is deallocated", not "becomes not
visible by the scope rules".  I guess I should have gotten that from
"when the execution leaves the block in which these variables were defined".

So the pattern I think I now see is this:  The constant reevaluation of the
expression involves reevaluating the operators and resampling the contents
of the variables, but not relooking the variables up by name.  Which means
my mention of changing context is irrelevant, because it would only affect
looking up by name.

Instead, the lookup of names is done exactly once, when the expression is
typed by the user, in the context of the current frame.  Thereafter, the only
context changes that matter are deallocation of one of the variables.  Do I
have it right?

If so, it still leaves me with a couple of different questions about things
that seem hard to implement:

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?

If the expression is *p and p stays in scope, but points to a local variable
that goes out of scope, does the watch get deleted then?

Presumably, if p points to a heap object that is deallocated, this is too
hard to detect and the watchpoint remains on the machine address.  Since
"deallocation" is often done by programmer-written allocators that the
language has no knowledge of, it would be hard to even define what it
means to deallocate.
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates@wichita.edu

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

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.

> If the expression is *p and p stays in scope, but points to a local variable
> that goes out of scope, does the watch get deleted then?

We have no way of knowing this, nor is it generally desirable (that
could be the very bug you are chasing).

> Presumably, if p points to a heap object that is deallocated, this is too
> hard to detect and the watchpoint remains on the machine address.  Since
> "deallocation" is often done by programmer-written allocators that the
> language has no knowledge of, it would be hard to even define what it
> means to deallocate.

Ditto.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

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

Re: breakpoint for accessing memory location

[Jim Blandy]

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.

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Cc: Daniel Jacobowitz <drow@false.org>,  rodney.bates@wichita.edu, 	  gdb@sourceware.org
> From: Jim Blandy <jimb@codesourcery.com>
> Date: Mon, 23 Oct 2006 15:02:30 -0700
> 
> 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.

Does the debug info tell us enough to do that?

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Tue, Oct 24, 2006 at 06:32:08AM +0200, Eli Zaretskii wrote:
> > 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.
> 
> Does the debug info tell us enough to do that?

Sometimes, but not reliably.  We delete out of scope watchpoints partly
by setting an appropriate breakpoint at the function return address,
and there is no equivalent exit address for nested scopes.

Another problem with watchpoints is that we don't support any kind of
location lists for local variables; that's a similar problem.

-- 
Daniel Jacobowitz
CodeSourcery

Re: breakpoint for accessing memory location

[Eli Zaretskii]

> Date: Tue, 24 Oct 2006 08:57:09 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Jim Blandy <jimb@codesourcery.com>, rodney.bates@wichita.edu,
> 	gdb@sourceware.org
> > 
> > Does the debug info tell us enough to do that?
> 
> Sometimes, but not reliably.

If so, I don't think GDB can do better than we do now, since only the
compiler knows the true scope of a variable.  Right?

> Another problem with watchpoints is that we don't support any kind of
> location lists for local variables

Again, does the debug info include such location lists?

Re: breakpoint for accessing memory location

[Daniel Jacobowitz]

On Tue, Oct 24, 2006 at 01:36:52PM -0400, Eli Zaretskii wrote:
> > Date: Tue, 24 Oct 2006 08:57:09 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: Jim Blandy <jimb@codesourcery.com>, rodney.bates@wichita.edu,
> > 	gdb@sourceware.org
> > > 
> > > Does the debug info tell us enough to do that?
> > 
> > Sometimes, but not reliably.
> 
> If so, I don't think GDB can do better than we do now, since only the
> compiler knows the true scope of a variable.  Right?

We can work out the scope from the debug info, in most cases; I was
thinking about the wrong data in my previous message.  But it's not
clear what we can _do_ with it.

DWARF-2 represents the PC ranges of lexical blocks at the source level.
You can see exactly where a variable ought to be in scope from that.
But unless you confine yourself to single-stepping, you won't know when
you leave that range.  You can't set a breakpoint at the end of it,
because it may contain jumps.

> > Another problem with watchpoints is that we don't support any kind of
> > location lists for local variables
> 
> Again, does the debug info include such location lists?

Yes.  It may say "0x4-0x12 var in %eax, 0x12-0x40 var in 8(%ebp),
otherwise var has no value".

-- 
Daniel Jacobowitz
CodeSourcery