qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] target-openrisc: bugfixes for debugging with GD


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] target-openrisc: bugfixes for debugging with GDB+Qemu on OpenRISC
Date: Mon, 5 Jan 2015 18:48:56 +0000

On 5 January 2015 at 18:41, David Morrison <address@hidden> wrote:
> 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

Well, it depends what semantics you want to define for the debug
stub. "Addresses are always physical addresses" isn't unreasonable
as a choice, but it's not what QEMU has picked -- we always use
virtual addresses if the MMU is enabled.

> 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.

Are you trying to give gdb physical addresses? That isn't
the way we define the gdbstub to work: you need to give
it virtual addresses.

-- PMM



reply via email to

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