Re: [Qemu-arm] ARMv7-M MemManage vector trap

[Elliot Buller]

Sorry I misspoke. I still need the MM fault active since my handler does some register patching necessary for normal operation. I just need to disable gdb from breaking when entering the ISR.

On Mon, May 21, 2018 at 11:59 AM Elliot Buller <address@hidden> wrote:

Hi Peter,

Yes, the current setup is qemu gdbstub connected to a local gdb instance. My first thought was to disable the corresponding signal in gdb to prevent it from trapping on the MM fault ISR but had no luck there (always stopped). I think the current behavior is probably what most users would want so it’s probably not worth patching upstream. If you could point me to a quick and dirty patch to disable MM faults on armv7-m that would be greatly appreciated. I’ve been looking at the code for a few days but haven’t made much progress...

Thanks,

Elliot

On Mon, May 21, 2018 at 10:07 AM Peter Maydell <address@hidden> wrote:

On 21 May 2018 at 16:31, Elliot Buller <address@hidden> wrote:
> I'm working on a body of code that relies heavily on the MPU faulting
> mechanism on cortex-m processors. This makes debugging other aspects
> difficult as GDB often traps in MPU fault while single stepping.
>
> On a real target it appears I can mask this by setting bit 4 of DEMCR (Debug
> Exception and Monitor Control Register). This looks to be unimplemented in
> QEMU. Does anyone have any ideas/guidance of where I should start looking to
> add support or another mechanism for disabling GDB trapping this ISR vector?

Is this gdb connected to QEMU's gdb stub?

DEMCR is part of the architectural support for halting debug. We
don't implement that, and our gdbstub doesn't work via halting
debug, so DEMCR is not what you're looking for.

I think that gdb-triggered accesses shouldn't actually cause us to generate
guest CPU exceptions (because the virt-to-phys calculation goes through
arm_cpu_get_phys_page_attrs_debug() and cpu_memory_rw_debug() rather than
the guest CPU's load/store codepaths). But it seems reasonable to me
that if the guest CPU can't read from an address then gdb reads should
also fail: this is how we handle it for other guest CPUs, I think.

thanks
-- PMM

--

Founder
Tiny Labs - Small Space Big Ideas

http://tinylabs.io

--

Founder
Tiny Labs - Small Space Big Ideas

http://tinylabs.io