From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32532 invoked by alias); 29 Jun 2010 00:46:52 -0000 Received: (qmail 32524 invoked by uid 22791); 29 Jun 2010 00:46:51 -0000 X-SWARE-Spam-Status: No, hits=-6.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; Tue, 29 Jun 2010 00:46:46 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5T0kiYg008393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jun 2010 20:46:44 -0400 Received: from mesquite.lan (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5T0khWQ020480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jun 2010 20:46:44 -0400 Date: Tue, 29 Jun 2010 00:46:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: Should we be able to read simulator memory immediately after a "load" command? Message-ID: <20100628174643.1552caea@mesquite.lan> In-Reply-To: <4C2936C8.8010002@vmware.com> References: <20100628130010.360f398d@mesquite.lan> <4C29213C.8020308@vmware.com> <20100628165514.5f408738@mesquite.lan> <4C2936C8.8010002@vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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-06/txt/msg00671.txt.bz2 On Mon, 28 Jun 2010 16:56:56 -0700 Michael Snyder wrote: > Kevin Buettner wrote: > > On Mon, 28 Jun 2010 15:25:00 -0700 > > Michael Snyder wrote: > > > >> Hmm, should we substitute "target_has_memory"? > >> > >> Is that set to TRUE after a load? > > > > If default_child_has_memory() is used, which is currently the case for > > the remote-sim target, it will not return TRUE after a "load", but > > before a "run". > > Hmmm. That sucks. ;-) In my opinion, the check in question can simply be removed. See below. Note that should the attempted memory read fail and return 0 bytes, the next target down the target stack will be consulted. (That's true though only so long as it's not running. Once it's running, then memory accesses are restricted to the current target. To see why this is so, examine the code around the to_has_all_memory() check in memory_xfer_partial().) * remote-sim.c (gdbsim_xfer_inferior_memory): Allow access to simulator once the program has been loaded, though not necessarily running. Index: remote-sim.c =================================================================== RCS file: /cvs/src/src/gdb/remote-sim.c,v retrieving revision 1.96 diff -u -p -r1.96 remote-sim.c --- remote-sim.c 16 May 2010 21:11:14 -0000 1.96 +++ remote-sim.c 29 Jun 2010 00:32:25 -0000 @@ -764,12 +764,6 @@ gdbsim_xfer_inferior_memory (CORE_ADDR m int write, struct mem_attrib *attrib, struct target_ops *target) { - /* If no program is running yet, then ignore the simulator for - memory. Pass the request down to the next target, hopefully - an exec file. */ - if (!target_has_execution) - return 0; - if (!program_loaded) error (_("No program loaded."));