Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Erik Leunissen <e.leunissen@hccnet.nl>
To: gdb@sourceware.org
Subject: Re: breakpoint for accessing memory location
Date: Fri, 20 Oct 2006 16:56:00 -0000	[thread overview]
Message-ID: <4538FF9D.9070803@hccnet.nl> (raw)
In-Reply-To: <u4ptzqz0b.fsf@gnu.org>

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




  parent reply	other threads:[~2006-10-20 16:56 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-19 20:10 Erik Leunissen
2006-10-19 20:12 ` Daniel Jacobowitz
2006-10-19 20:24   ` Erik Leunissen
2006-10-19 20:25     ` Daniel Jacobowitz
2006-10-19 20:28       ` Erik Leunissen
2006-10-20  6:31     ` Eli Zaretskii
2006-10-20 14:27       ` Daniel Jacobowitz
2006-10-21 13:20         ` [commit] Fix annotations-related index entries (was: breakpoint for accessing memory location) Eli Zaretskii
2006-10-20 16:56       ` Erik Leunissen [this message]
2006-10-20 17:39         ` breakpoint for accessing memory location Eli Zaretskii
2006-10-21 12:58         ` Eli Zaretskii
2006-10-21 22:28           ` Erik Leunissen
2006-10-22  4:20             ` Eli Zaretskii
2006-10-22  9:11               ` Erik Leunissen
2006-10-22  9:19                 ` Erik Leunissen
2006-10-22 22:16                 ` Eli Zaretskii
2006-10-23  7:41                   ` Erik Leunissen
2006-10-21 15:06       ` Rodney M. Bates
2006-10-21 15:27         ` Daniel Jacobowitz
2006-10-21 15:29         ` Eli Zaretskii
2006-10-21 15:51           ` Daniel Jacobowitz
2006-10-21 21:26             ` Eli Zaretskii
2006-10-21 22:32               ` Daniel Jacobowitz
2006-10-22  4:18                 ` Eli Zaretskii
2006-10-22  4:22                   ` Daniel Jacobowitz
2006-10-22 12:18                     ` Robert Dewar
2006-10-22 22:18                       ` Eli Zaretskii
2006-10-22 22:21                         ` Daniel Jacobowitz
2006-10-22 22:29                           ` Eli Zaretskii
2006-10-22 22:49                             ` Robert Dewar
2006-10-22 23:18                             ` Daniel Jacobowitz
2006-10-23  2:03                               ` Robert Dewar
2006-10-23  4:11                               ` Eli Zaretskii
2006-10-23 12:36                                 ` Daniel Jacobowitz
2006-10-22 22:48                         ` Robert Dewar
2006-10-22 22:51                           ` Eli Zaretskii
2006-10-22 22:55                             ` Robert Dewar
2006-10-23  4:10                               ` Eli Zaretskii
2006-10-22 20:40                     ` Mark Kettenis
2006-10-21 18:07           ` Rodney M. Bates
2006-10-21 21:42             ` Eli Zaretskii
2006-10-21 18:55           ` Rodney M. Bates
2006-10-21 21:53             ` Eli Zaretskii
2006-10-22 15:20               ` Rodney M. Bates
2006-10-22 17:24                 ` Daniel Jacobowitz
2006-10-22 22:22                   ` Eli Zaretskii
2006-10-23 22:02                     ` Jim Blandy
2006-10-24  4:32                       ` Eli Zaretskii
2006-10-24 12:57                         ` Daniel Jacobowitz
2006-10-24 17:37                           ` Eli Zaretskii
2006-10-24 17:41                             ` Daniel Jacobowitz

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=4538FF9D.9070803@hccnet.nl \
    --to=e.leunissen@hccnet.nl \
    --cc=gdb@sourceware.org \
    /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