From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28877 invoked by alias); 6 Oct 2010 20:55:53 -0000 Received: (qmail 28869 invoked by uid 22791); 6 Oct 2010 20:55:52 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from gate.lvk.cs.msu.su (HELO mail.lvk.cs.msu.su) (158.250.17.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Oct 2010 20:55:47 +0000 Received: from mail.lvk.cs.msu.su (localhost [127.0.0.1]) by mail.lvk.cs.msu.su (Postfix) with ESMTP id C58BA6E82; Thu, 7 Oct 2010 00:55:41 +0400 (MSD) X-Spam-ASN: Received: from thunder.localnet (h86-62-88-129.ln.rinet.ru [86.62.88.129]) by mail.lvk.cs.msu.su (Postfix) with ESMTPSA id B47AF6780; Thu, 7 Oct 2010 00:55:41 +0400 (MSD) From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: [patch] fix pre-/post- in-/decrement Date: Wed, 06 Oct 2010 20:55:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-22-generic-pae; KDE/4.5.1; i686; ; ) Cc: Ulrich Weigand , Ken Werner , gdb-patches@sourceware.org, Joel Brobecker References: <20101005011650.GF6985@caradoc.them.org> <201010051328.o95DSJ8L027985@d12av02.megacenter.de.ibm.com> <20101005134200.GJ6985@caradoc.them.org> In-Reply-To: <20101005134200.GJ6985@caradoc.them.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010070055.29428.vladimir@codesourcery.com> X-AV-Checked: ClamAV using ClamSMTP 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-10/txt/msg00085.txt.bz2 On Tuesday, October 05, 2010 17:42:01 you wrote: > On Tue, Oct 05, 2010 at 03:28:19PM +0200, Ulrich Weigand wrote: > > Daniel Jacobowitz wrote: > > > On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote: > > > > - If you execute "set *$p = *$q = 0" and the write to *$q fails, > > > > > > > > do you really expect *$p to be set to the old value of *$q > > > > instead of to 0? > > > > > > Yes, I would expect that. To me, this is roughly "the debugger treats > > > all pointers as volatile". > > > > The thing is, I had interpreted the C standard to read that even if > > pointers p and q *are* volatile, a statement like "*p = *q = 0" would > > still just trigger two writes, and no reads. > > You're right, I remember Nathan's recent arguments about this on > gcc-patches. > > > "Assignments are also expressions and have an rvalue. However when > > assigning to a scalar volatile, the volatile object is not reread, > > regardless of whether the assignment expression's rvalue is used or not. > > If the assignment's rvalue is used, the value is that assigned to the > > volatile object. [...] If you need to read the volatile object after an > > assignment has occurred, you must use a separate expression with an > > intervening sequence point." > > > > To reduce the potential for confusion, it seems to me GDB ought to mirror > > that behavior as well ... > > Hmm. > > It seems to me that this is a disruptive change for us, because the "a > = b" case is more likely to be used than anything fancy (a += b, a = b > = c). If we change it, we should document the change. > > Vladimir, would this interact with your recent varobj changes? We > worked out exactly which reads we wanted, but I don't remember if > value_assign is involved. I don't think value_assign was involved in my changes -- instead, I have modified varobj_set_value to do a read-back of the value being assigned to. I am not entirely sure whether on CLI, one wants: print $io.whatever = 10 to print '10' or the value in $io.whatever. Maybe, following C rules has some sense here. On the other hand, in GUI there's no assignment expression, so C standard is probably not a useful analogue. So, I guess this patch is compatible with our changes. - Volodya