qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-trivial] [Qemu-devel] [PATCH] target-openrisc: bugfixes for de


From: David Morrison
Subject: Re: [Qemu-trivial] [Qemu-devel] [PATCH] target-openrisc: bugfixes for debugging with GDB+Qemu on OpenRISC
Date: Mon, 05 Jan 2015 10:41:31 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

Hi, Peter,

Thanks for the response. I'll split out the changes into separate commits and resubmit. I do have one question here:


diff --git a/target-openrisc/mmu.c b/target-openrisc/mmu.c
index 750a936..bbd05f1 100644
--- a/target-openrisc/mmu.c
+++ b/target-openrisc/mmu.c
@@ -219,7 +219,7 @@ hwaddr openrisc_cpu_get_phys_page_debug(CPUState *cs, vaddr 
addr)
      hwaddr phys_addr;
      int prot;

-    if (cpu_openrisc_get_phys_addr(cpu, &phys_addr, &prot, addr, 0)) {
+    if (cpu_openrisc_get_phys_nommu(cpu, &phys_addr, &prot, addr, 0)) {

This looks wrong -- we won't do the virtual-to-physical
translation on the addresses provided by the debugger if
we use the _nommu() function. You definitely need to be
doing a v-to-p translation here somehow.


I was similarly puzzled by this. However, I've been comparing Qemu to or1ksim, which does not appear to do translation for the debugger; see the following code excerpt from the or1ksim source:

https://github.com/openrisc/or1ksim/blob/or1k-master/debug/rsp-server.c#L1546

rsp_read_mem (struct rsp_buf *buf)
{
...
  for (off = 0; off < len; off++)
    {
      unsigned char  ch;        /* The byte at the address */

      /* Check memory area is valid */
      ...

      // Get the memory direct - no translation.
      ch = eval_direct8 (addr + off, 0, 0);

      buf->data[off * 2]     = hexchars[ch >>   4];
      buf->data[off * 2 + 1] = hexchars[ch &  0xf];
    }

  buf->data[off * 2] = 0;           /* End of string */
  buf->len           = strlen (buf->data);
  put_packet (buf);

}   /* rsp_read_mem () */

Moreover, in Qemu if you perform the translation and use GDB to debug, it returns bogus values for the memory read, whereas not performing the translation appears to work correctly. Am I doing something wrong here, or is this possibly a bug in the or1k toolchain instead?

Thanks for your help!
David

--
David R. Morrison, PhD
Inverse Limit
address@hidden
+1-217-417-9445



reply via email to

[Prev in Thread] Current Thread [Next in Thread]