[Qemu-devel] Single stepping & GDB on ARM

[Qemu-devel] Single stepping & GDB on ARM

[Emmanuel Blot]

Hi,

Is there a way to halt the execution of the VM on the *first*
unassigned memory access, and let the guest GDB take over to debug the
invalid access?

I noticed that cpu_unassigned_access() is not implemented on ARM. Is
this a missing feature - yet to be implemented, or something that
cannot be supported on ARM plartform for some reason?

Thanks,
Manu.

Re: [Qemu-devel] Single stepping & GDB on ARM

[Peter Maydell]

On 17 September 2013 09:47, Emmanuel Blot <eblot.ml@gmail.com> wrote:
> I noticed that cpu_unassigned_access() is not implemented on ARM. Is
> this a missing feature - yet to be implemented, or something that
> cannot be supported on ARM plartform for some reason?

No, it should cause an external abort exception, really. It's
just nobody's needed it (guest OSes should never do anything
that provokes an external abort unless they're buggy) so nobody's
bothered doing it yet. Also when it's added various boards need
testing to see how much they're relying on the current "unassigned
RAM returns 0" to cover up for missing device models, which
is a bit tedious given how many boards we have.

-- PMM

Re: [Qemu-devel] Single stepping & GDB on ARM

[Emmanuel Blot]

> No, it should cause an external abort exception, really.

Ok.

> It's just nobody's needed it (guest OSes should never do anything
> that provokes an external abort unless they're buggy) so nobody's
> bothered doing it yet.

Understood. Thanks.

I'm using QEMU to debug a platform (ARM7TDMI) + OS (eCos) that do not
support a MMU,
so external aborts sometimes occur. The supported ARM946 (which only
has a MPU) is likely
to produce the same type of errors. I guess it is a marginal use of QEMU though.

> Also when it's added various boards need
> testing to see how much they're relying on the current "unassigned
> RAM returns 0" to cover up for missing device models, which
> is a bit tedious given how many boards we have.

Ok. Got it.

There is a piece of code I'm not sure to understand, in
   get_page_addr_code(CPUArchState *env1, target_ulong addr)

…
    if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code !=
                 (addr & TARGET_PAGE_MASK))) {
        cpu_ldub_code(env1, addr);
    }
    pd = env1->iotlb[mmu_idx][page_index] & ~TARGET_PAGE_MASK;
    mr = iotlb_to_region(pd);
    if (memory_region_is_unassigned(mr))
…

cpu_ldub_code() leads to call io_mem_read() which may trigger a
unassigned_mem_read().
In this case, the invalid mem access is always considered as a data
access, whereas it is an execution access if I'm not mistaken.

In other words, before
get_page_addr_code:memory_region_is_unassigned() is tested and
get_page_addr_code:do_unassigned_access() gets a "chance" to be called
as an "instruction" invalid access, another unsigned access is
triggered with a "data" invalid access.

Did I miss something here?

Would you have any advice on how to stop the execution of the VCPU on
the first invalid memory access (in single step mode)?

Thanks for your help,
Manu.

Re: [Qemu-devel] Single stepping & GDB on ARM

[Richard Henderson]

On 09/17/2013 03:02 AM, Emmanuel Blot wrote:
> There is a piece of code I'm not sure to understand, in
>    get_page_addr_code(CPUArchState *env1, target_ulong addr)
> 
> …
>     if (unlikely(env1->tlb_table[mmu_idx][page_index].addr_code !=
>                  (addr & TARGET_PAGE_MASK))) {
>         cpu_ldub_code(env1, addr);
>     }
>     pd = env1->iotlb[mmu_idx][page_index] & ~TARGET_PAGE_MASK;
>     mr = iotlb_to_region(pd);
>     if (memory_region_is_unassigned(mr))
> …
> 
> cpu_ldub_code() leads to call io_mem_read() which may trigger a
> unassigned_mem_read().
> In this case, the invalid mem access is always considered as a data
> access, whereas it is an execution access if I'm not mistaken.
> 
> In other words, before
> get_page_addr_code:memory_region_is_unassigned() is tested and
> get_page_addr_code:do_unassigned_access() gets a "chance" to be called
> as an "instruction" invalid access, another unsigned access is
> triggered with a "data" invalid access.
> 
> Did I miss something here?

No miss.  That cpu_ldub_code ought to be just a straight tlb fill,
rather than a read with discarded result.  E.g. the

  tlb_fill(env, addr, READ_ACCESS_TYPE, mmu_idx, retaddr);

line from exec/softmmu_template.h.


r~