From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23155 invoked by alias); 4 Oct 2010 23:25:04 -0000 Received: (qmail 23127 invoked by uid 22791); 4 Oct 2010 23:25:02 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate2.de.ibm.com (HELO mtagate2.de.ibm.com) (195.212.17.162) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 04 Oct 2010 23:24:57 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.13.1/8.13.1) with ESMTP id o94NOrTl001844 for ; Mon, 4 Oct 2010 23:24:53 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o94NOqPN4137130 for ; Tue, 5 Oct 2010 01:24:52 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id o94NOqJE021766 for ; Tue, 5 Oct 2010 01:24:52 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id o94NOp3Y021755; Tue, 5 Oct 2010 01:24:51 +0200 Message-Id: <201010042324.o94NOp3Y021755@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Tue, 05 Oct 2010 01:24:51 +0200 Subject: Re: [patch] fix pre-/post- in-/decrement To: dan@codesourcery.com (Daniel Jacobowitz) Date: Mon, 04 Oct 2010 23:25:00 -0000 From: "Ulrich Weigand" Cc: ken@linux.vnet.ibm.com (Ken Werner), gdb-patches@sourceware.org, brobecker@adacore.com (Joel Brobecker) In-Reply-To: <20101004225938.GZ6985@caradoc.them.org> from "Daniel Jacobowitz" at Oct 04, 2010 06:59:38 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00035.txt.bz2 Daniel Jacobowitz wrote: > On Mon, Oct 04, 2010 at 11:57:47PM +0200, Ulrich Weigand wrote: > > It would appear that even the current behavior, as shown in your trace, > > already contains an unnecessary load. There should be no need to perform > > a memory read to evaluate "print *$p = 1". > > In fact, we rely on this unintuitive behavior. If you write to any > kind of memory other than RAM, then it's not possible for GDB to > predict what value was actually written. Suppose you write a value to > ROM with "print"; GDB should show the old value, to reflect that the > variable was not modified. 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. 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? - 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? - 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com