From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8939 invoked by alias); 20 May 2010 17:03:19 -0000 Received: (qmail 8825 invoked by uid 22791); 20 May 2010 17:03:16 -0000 X-SWARE-Spam-Status: No, hits=-5.8 required=5.0 tests=AWL,BAYES_00,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; Thu, 20 May 2010 17:03:11 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o4KH39n3006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 20 May 2010 13:03:09 -0400 Received: from psique.localnet (vpn-242-33.phx2.redhat.com [10.3.242.33]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o4KH38Ck018025; Thu, 20 May 2010 13:03:09 -0400 From: Sergio Durigan Junior To: gdb-patches@sourceware.org Subject: Re: [PATCH] Forbid watchpoint on a constant value Date: Thu, 20 May 2010 17:06:00 -0000 User-Agent: KMail/1.13.2 (Linux/2.6.32.11-99.fc12.x86_64; KDE/4.4.2; x86_64; ; ) Cc: Jan Kratochvil References: <201005181418.24324.sergiodj@redhat.com> <201005201313.02076.sergiodj@redhat.com> <20100520164735.GA25121@host0.dyn.jankratochvil.net> In-Reply-To: <20100520164735.GA25121@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005201403.07723.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/msg00425.txt.bz2 On Thursday 20 May 2010 13:47:35, Jan Kratochvil wrote: > On Thu, 20 May 2010 18:13:01 +0200, Sergio Durigan Junior wrote: > > On Thursday 20 May 2010 12:29:42, Jan Kratochvil wrote: > > > On Thu, 20 May 2010 07:10:26 +0200, Sergio Durigan Junior wrote: > > > > + case BINOP_ASSIGN: > > > > + case BINOP_ASSIGN_MODIFY: > > > > + case OP_FUNCALL: > > > > + case OP_OBJC_MSGCALL: > > > > + case OP_F77_UNDETERMINED_ARGLIST: > > > > + case UNOP_PREINCREMENT: > > > > + case UNOP_POSTINCREMENT: > > > > + case UNOP_PREDECREMENT: > > > > + case UNOP_POSTDECREMENT: > > > > > > This is not a `const'/`pure' function, it has some side-effect of the > > > assignment. I do not thing they should be caught as constant. > > > > Sorry, I didn't understand why they can't be considered constant in the > > context of a watchpoint. > > echo 'int v;main(){}'|gcc -o 1 -x c - -g;./gdb -nx -ex 'p v' -ex 'watch v=1' -ex start -ex 'p v' ./1 > > The output of last > -ex 'p v' > will change if you include / not include > -ex 'watch v=1' > so that 'watch v=1' is not a NOP without meaning. > > Someone may use it in existing scripts to set variable `v' this way. > > I understand it is very broken idea to modify variables from watchpoint > expression. Just I did not find it too useful to check here and when such > patch could change the GDB behavior I find it more a disadvantage than an > advantage. > > But I do not have a strong opinion on it. Ok, now I've got it. I really wasn't considering this option because I would never modify a variable's value this way, but you're right. > > > > + case BINOP_VAL: > > > > + case BINOP_INCL: > > > > + case BINOP_EXCL: > > > > + case UNOP_PLUS: > > > > + case UNOP_CAP: > > > > + case UNOP_CHR: > > > > + case UNOP_ORD: > > > > + case UNOP_ABS: > > > > + case UNOP_FLOAT: > > > > + case UNOP_MAX: > > > > + case UNOP_MIN: > > > > + case UNOP_ODD: > > > > + case UNOP_TRUNC: > > > > > > I do not see implemented evaluation of these, also their processing should > > > have been probably moved to some m2-* file. > > > > Does it mean that I have to remove them from this list? > > There is a problem these operators have no implementation in the current GDB > sources. Therefore one cannot verify what they do and if they are or they are > not constant. How did you verify BINOP_VAL does not depend on some possibly > changing value? The comments at their definition may not be always right. > > As they are also not useful to be used in an expression when no processing of > them is implemented I find more dangerous to make some - possibly invalid > - assumptions about them (that they are constant - they possibly may be > implemented in a non-constant way in the future). > > The note about move to a different file was invalid, described in the very > last comment of my mail. Sorry, I just blindly added those types to the list based on their comments. I will remove them, thanks for the explanation. > > > > + case OP_INTERNALVAR: > > > > > > I would guess value of some of the internal variables can change. > > > > Is the user allowed to put a watchpoint on an internal variable? > > It seems to me so: > (gdb) watch $a > Watchpoint 2: $a > Although the watchpoint does not get hit when $a gets modified during inferior > run. Unaware why. I really didn't know you could ask GDB to trigger when an internal variable changes. But OK, living and learning ;-). Will send the refreshed patch later today. Thanks, -- Sergio Durigan Junior Red Hat