From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21169 invoked by alias); 5 Oct 2010 01:17:14 -0000 Received: (qmail 21161 invoked by uid 22791); 5 Oct 2010 01:17:13 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Oct 2010 01:17:05 +0000 Received: (qmail 4467 invoked from network); 5 Oct 2010 01:17:04 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Oct 2010 01:17:04 -0000 Date: Tue, 05 Oct 2010 01:17:00 -0000 From: Daniel Jacobowitz To: Ulrich Weigand Cc: Ken Werner , gdb-patches@sourceware.org, Joel Brobecker Subject: Re: [patch] fix pre-/post- in-/decrement Message-ID: <20101005011650.GF6985@caradoc.them.org> References: <20101004225938.GZ6985@caradoc.them.org> <201010042324.o94NOp3Y021755@d12av02.megacenter.de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201010042324.o94NOp3Y021755@d12av02.megacenter.de.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00038.txt.bz2 On Tue, Oct 05, 2010 at 01:24:51AM +0200, Ulrich Weigand wrote: > Well, this behavior clearly seems an accident in the current code; > you get this only if the target of the assignment happened to be > a lazy value before value_assign. For example, while you do get > the extra read after: > print *$p = 1 > you get *no* extra read after: > print *$p += 1 > > This seems inconsistent, at the very least. Yes, yes it is. I was not aware of this. I think Vladimir has also fixed some bugs in this area for varobjs; I don't know if that was posted yet. > In any case, I'm wondering a bit why you prefer this behavior; this > seems to have quite unexpected consequences to me: > > - 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". > - If *$p is a memory-mapped register where reading and writing have > different effects, should assigning to *$p really trigger *both* > a write and a read cycle, even though a C assignment wouldn't? If you say "print", yes. If you don't want this behavior - often I don't - then use set. > - In the case you refer to where writing to ROM fails, shouldn't > we actually get an error thrown anyway? Writing to an unmapped > address does that as well ... Well, possibly. It depends on the system. It's very useful to be able to use GDB to generate bus cycles. And, for instance, I sometimes use GDB to poke at a flash device; it's programmable, but not in the straightforward write-to-memory way that RAM is. -- Daniel Jacobowitz CodeSourcery