This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Forbid watchpoint on a constant value
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Joel Brobecker <brobecker at adacore dot com>, Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 21 May 2010 09:05:00 +0200
- Subject: Re: [PATCH] Forbid watchpoint on a constant value
On Fri, 21 May 2010 01:13:08 +0200, Joel Brobecker wrote:
> > (gdb) watch 5
> > Cannot watch constant value 5.
[...]
> For myself, I can see how a warning might be useful, but forbidding it might
> be viewed as a little excessive,
`watch 5' can never trigger. I cannot agree with creating a watchpoint which
will never trigger. Watchpoint which gets out of scope also gets removed.
$ echo 'f(){int v;v++;}main(){f();}'|gcc -o 1 -g -x c -;gdb -nx -ex 'b f' -ex r -ex 'watch v' -ex fini -ex 'info watch' ./1
Watchpoint 2 deleted because the program has left the block in
which its expression is valid.
[...]
No watchpoints.
> particularly if there is a bug in GDB (or in the debugging info!!!) that
> makes it think it's constant when in fact it's not.
It is true this patch has in fact two parts. The first one is just about
constants - such as `watch 5' or `watch 1 + 2'. Those can never trigger as it
would be a GDB internal error otherwise. IMO this patch part is clearly a win.
The more problematic is the part
const i = 5;
(gdb) watch i
+ case OP_VAR_VALUE:
+ if (TYPE_CODE (SYMBOL_TYPE (s)) != TYPE_CODE_FUNC
+ && !TYPE_CONST (SYMBOL_TYPE (s)))
+ return 0;
as you are right that a symbol can be tagged by buggy compiler as
DW_TAG_const_type despite its value changes in the compiler output. Another
possibility is a memory corruption. On both -O0 -g and -O2 -g output it can
change during:
$ echo 'const int v;main(){*(int*)&v=1;}'|gcc -o 1 -g -x c -;gdb -nx -ex 'watch v' -ex r ./1
Hardware watchpoint 1: v
Old value = 0
New value = 1
It is true GDB is used in the cases of memory corruption so such watchpoint can
be useful. (OTOH `p &var' and `watch *(type *)that_address' is used daily by
GDB users lacking Apple `watch -location' and it workarounds it easily.)
On Fri, 21 May 2010 01:34:49 +0200, Joel Brobecker wrote:
> What was your own motivation behind this? I guess some user inserted
> a watchpoint on something constant, and then waited for ages for the
> watchpoint to trigger,
The repeating case from real world users is the `watch 5' case and it is
described in the submitted doc part:
+If you watch for a change in a numerically entered address you need to
+dereference it, as the address itself is just a constant number which will
+never change.
+(@value{GDBP}) watch 0x600850
+Cannot watch constant value 0x600850.
+(@value{GDBP}) watch *(int *) 0x600850
+Watchpoint 1: *(int *) 6293584
The second part about watching constant variables is a made up one, when the
first part got already written. While I find it myself as useful I cannot
back it by existing real users experienced difficulties.
This case
$ echo 'main(){const int v;*(int*)&v=1;}'|gcc -o 1 -O2 -g -x c -;gdb -nx -ex start -ex 'watch v' -ex c ./1
gets compiled as:
<2><4b>: Abbrev Number: 3 (DW_TAG_variable)
<4c> DW_AT_name : v
<54> DW_AT_const_value : 1
which would be a GDB internal error if it would ever trigger.
A safer patch would be to check SYMBOL_CLASS for LOC_CONST/etc. of the
variable instead of relying on compiler's DW_TAG_const_type correctness.
Thanks,
Jan