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: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Joel Brobecker <brobecker at adacore dot com>, Sergio Durigan Junior <sergiodj at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 27 May 2010 20:03:04 -0600
- Subject: Re: [PATCH] Forbid watchpoint on a constant value
- References: <201005202054.53548.sergiodj@redhat.com> <20100521070500.GA30452@host0.dyn.jankratochvil.net>
- Reply-to: 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