From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23763 invoked by alias); 28 Jun 2010 22:25:08 -0000 Received: (qmail 23752 invoked by uid 22791); 28 Jun 2010 22:25:07 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 28 Jun 2010 22:25:03 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 0AD2052004; Mon, 28 Jun 2010 15:25:01 -0700 (PDT) Received: from msnyder-server.eng.vmware.com (promd-2s-dhcp138.eng.vmware.com [10.20.124.138]) by mailhost2.vmware.com (Postfix) with ESMTP id EF7C18E620; Mon, 28 Jun 2010 15:25:00 -0700 (PDT) Message-ID: <4C29213C.8020308@vmware.com> Date: Mon, 28 Jun 2010 22:25:00 -0000 From: Michael Snyder User-Agent: Thunderbird 2.0.0.22 (X11/20090609) MIME-Version: 1.0 To: Kevin Buettner CC: "gdb-patches@sourceware.org" Subject: Re: Should we be able to read simulator memory immediately after a "load" command? References: <20100628130010.360f398d@mesquite.lan> In-Reply-To: <20100628130010.360f398d@mesquite.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00667.txt.bz2 Kevin Buettner wrote: > In the course of debugging a program in which the LMA and VMA of > certain segments differ, we've noticed that simulator memory cannot be > read immediately after a issuing a "load" command. One needs to "run" > the program first in order to be able to access simulator memory. > > In our debugging scenario, the fact that the LMA differs from the VMA > is only significant in that when they're the same, you tend to get the > expected results when attempting to read memory immediately after the > "load" due to the fact that GDB does memory fetches using the exec > file. When the LMA and VMA are different, the exec file provides > access to memory at the VMA addresses, but not at LMA addresses. > When using the simulator (or a remote target), I would expect to > be able to read memory located at a valid LMA addresss. Memory at > at a VMA address may or may not be available yet; it will most likely be > initialized early on during execution of the program. > > The code responsible for disallowing access to simulator memory after > a "load", but before a "run" appears as follows in > gdbsim_xfer_inferior_memory(): > > /* 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; > > This code was added in a patch from 2006. See: > > http://sourceware.org/ml/gdb-patches/2006-10/msg00042.html > > In that posting, Daniel provides a good rationale for that patch as a > whole, but I did not see any discussion of the portion affecting > gdbsim_xfer_inferior_memory(). > > So, the obvious question... Is there any good reason to prohibit > access to the simulator's memory immediately after a load? > > (If not, I'll post a patch removing that restriction...) Hmm, should we substitute "target_has_memory"? Is that set to TRUE after a load?