Re: [Qemu-trivial] [Qemu-devel] [PATCH] target-openrisc: bugfixes for debugging with GDB+Qemu on OpenRISC

[David Morrison <dmorrison@invlim.com>]

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
dmorrison@invlim.com
+1-217-417-9445