From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5733 invoked by alias); 28 Jun 2010 20:00:19 -0000 Received: (qmail 5708 invoked by uid 22791); 28 Jun 2010 20:00:17 -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; Mon, 28 Jun 2010 20:00:12 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5SK0B8u017412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Jun 2010 16:00:11 -0400 Received: from mesquite.lan (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5SK0AJN025076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 28 Jun 2010 16:00:11 -0400 Date: Mon, 28 Jun 2010 20:00:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Should we be able to read simulator memory immediately after a "load" command? Message-ID: <20100628130010.360f398d@mesquite.lan> 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/msg00656.txt.bz2 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...) Kevin