From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22709 invoked by alias); 21 May 2010 21:24:42 -0000 Received: (qmail 22700 invoked by uid 22791); 21 May 2010 21:24:41 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,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 21:24:37 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4LLON3v009774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 May 2010 17:24:23 -0400 Received: from psique.localnet (vpn-226-71.phx2.redhat.com [10.3.226.71]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4LLOM8Q020251; Fri, 21 May 2010 17:24:23 -0400 From: Sergio Durigan Junior To: Jan Kratochvil Subject: Re: [PATCH] Forbid watchpoint on a constant value Date: Fri, 21 May 2010 21:43:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32.11-99.fc12.x86_64; KDE/4.4.2; x86_64; ; ) Cc: Joel Brobecker , gdb-patches@sourceware.org References: <20100521070500.GA30452@host0.dyn.jankratochvil.net> In-Reply-To: <20100521070500.GA30452@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005211824.20290.sergiodj@redhat.com> 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/msg00517.txt.bz2 On Friday 21 May 2010 04:05:00, Jan Kratochvil wrote: > 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. `watch var = 5' will never trigger as well, but we've decided to accept it anyway. But I understand your point. > 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 I can make the function return a different code in the case of OP_VAR_VALUE, so that watch_command_1 will know if we're dealing with a _possible_ constant value (and then asks the user if she really wants to put a watchpoint in that variable, as Eli suggested). WDYT? > 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. Ok, I will change my patch to use SYMBOL_CLASS and will resubmit it. Thanks, -- Sergio Durigan Junior Red Hat