Re: [PATCH] Forbid watchpoint on a constant value

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

I finally read through this thread today.

Jan> `watch 5' can never trigger.  I cannot agree with creating a
Jan> watchpoint which will never trigger.

I agree.  A watchpoint like that is most likely user error.

Jan> The more problematic is the part
Jan> 	const i = 5;
Jan> 	(gdb) watch i
Jan> +       case OP_VAR_VALUE:
Jan> +           if (TYPE_CODE (SYMBOL_TYPE (s)) != TYPE_CODE_FUNC
Jan> +               && !TYPE_CONST (SYMBOL_TYPE (s)))
Jan> +             return 0;
Jan> as you are right that a symbol can be tagged by buggy compiler as
Jan> DW_TAG_const_type despite its value changes in the compiler output.
Jan> Another possibility is a memory corruption.

I think that we cannot rely on DW_TAG_const_type in this situation.  As
you note, programs may cast it away, or there could be corruption -- the
latter is exactly when it would be useful to put a watchpoint on such a
variable.  Also, in C++ I believe you can have a const object with a
mutable member, which this test does not detect.

Jan> 	 <2><4b>: Abbrev Number: 3 (DW_TAG_variable)
Jan> 	    <4c>   DW_AT_name        : v        
Jan> 	    <54>   DW_AT_const_value : 1        
Jan> which would be a GDB internal error if it would ever trigger.

Jan> A safer patch would be to check SYMBOL_CLASS for LOC_CONST/etc. of the
Jan> variable instead of relying on compiler's DW_TAG_const_type correctness.

Yes, I agree.  In this situation gdb has no way of detecting any change
to the value anyhow.

Tom