Re: [PATCH] Forbid watchpoint on a constant value

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

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