From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Uq5nP-0001v0-KL for qemu-devel@nongnu.org; Fri, 21 Jun 2013 14:10:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Uq5nO-0002MO-E6 for qemu-devel@nongnu.org; Fri, 21 Jun 2013 14:10:51 -0400 Message-ID: <51C49726.1050404@siemens.com> Date: Fri, 21 Jun 2013 20:10:46 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1371567181-4917-1-git-send-email-chouteau@adacore.com> <1371567181-4917-2-git-send-email-chouteau@adacore.com> <023DE6D4-A858-4159-BF3E-8CD02B0B01BB@suse.de> In-Reply-To: <023DE6D4-A858-4159-BF3E-8CD02B0B01BB@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] PPC: Fix GDB read on code area for PPC6xx List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org list:PowerPC" , qemu-devel qemu-devel , Fabien Chouteau On 2013-06-18 17:34, Alexander Graf wrote: > > On 18.06.2013, at 16:53, Fabien Chouteau wrote: > >> On PPC 6xx, data and code have separated TLBs. Until now QEMU was only >> looking at data TLBs, which is not good when GDB wants to read code. >> >> This patch adds a second call to get_physical_address() with an >> ACCESS_CODE type of access when the first call with ACCESS_INT fails. >> >> Signed-off-by: Fabien Chouteau >> --- >> target-ppc/mmu_helper.c | 10 +++++++++- >> 1 file changed, 9 insertions(+), 1 deletion(-) >> >> diff --git a/target-ppc/mmu_helper.c b/target-ppc/mmu_helper.c >> index 910e022..19f0b8c 100644 >> --- a/target-ppc/mmu_helper.c >> +++ b/target-ppc/mmu_helper.c >> @@ -1378,7 +1378,15 @@ hwaddr cpu_get_phys_page_debug(CPUPPCState *env, target_ulong addr) >> } >> >> if (unlikely(get_physical_address(env, &ctx, addr, 0, ACCESS_INT) != 0)) { >> - return -1; >> + >> + /* Some MMUs have separate TLBs for code and data. If we only try an >> + * ACCESS_INT, we may not be able to read instructions mapped by code >> + * TLBs, so we also try a ACCESS_CODE. > > This is pretty ugly, but I don't see any other way to conveniently give gdb the information it needs. Let's ask Jan whether he has an idea. Maybe a monitor command to switch memory access modes? I suppose the gdb frontend is not willing to tell us what kind of memory it accesses (code disassembling or data access etc.), right? So we can only guess here, ie. try both. I don't see how a monitor-based side channel could help. If we touched gdb, we could also touch the remote protocol (for memory accesses). Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux