From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12644 invoked by alias); 21 May 2010 07:05:35 -0000 Received: (qmail 12629 invoked by uid 22791); 21 May 2010 07:05:33 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,FAKE_REPLY_C,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 21 May 2010 07:05:28 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4L755iC030386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 03:05:05 -0400 Received: from host0.dyn.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4L7528C025383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 May 2010 03:05:04 -0400 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.4/8.14.4) with ESMTP id o4L752PJ031456; Fri, 21 May 2010 09:05:02 +0200 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.4/8.14.4/Submit) id o4L751Th031443; Fri, 21 May 2010 09:05:01 +0200 Date: Fri, 21 May 2010 08:44:00 -0000 From: Jan Kratochvil To: Joel Brobecker , Sergio Durigan Junior Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Forbid watchpoint on a constant value Message-ID: <20100521070500.GA30452@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201005202054.53548.sergiodj@redhat.com> <20100520233449.GO3019@adacore.com> <20100520231308.GM3019@adacore.com> User-Agent: Mutt/1.5.20 (2009-08-17) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00476.txt.bz2 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