* [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults
@ 2014-02-17 14:52 Andreas Galauner
2014-02-17 15:18 ` Peter Maydell
0 siblings, 1 reply; 4+ messages in thread
From: Andreas Galauner @ 2014-02-17 14:52 UTC (permalink / raw)
To: qemu-devel
Hi qemu developers,
I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the
system using GDB and IDA Pro. The platform is an STM32 and I'm using a
port from github [1] based on qemu 1.5.1 for that. I ported the custom
STM32 code to qemu 1.7.0 to have a more recent version to work with.
During a debug session, I'm experiencing segfaults in armv7m_nvic.c when
reading the CPUID and Vector base registers (lines 176 and 212), because
ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite
regularly. Debugging with GDB works until you try to read the mentioned
registers by hand like this:
> (gdb) target remote :1234
> Remote debugging using :1234
> 0x08005d1c in ?? ()
> (gdb) x/x *0xE000ED00
> Remote connection closed
The original STM32-port was based on qemu 1.5.1 and the behaviour was
the same. That was the reason why I ported all that stuff over to 1.7.0
which unfortunately didn't solve the problem.
Is this a known bug?
Any hints on how I could possibly solve that problem?
- Andy
[1]: https://github.com/beckus/qemu_stm32
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults 2014-02-17 14:52 [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults Andreas Galauner @ 2014-02-17 15:18 ` Peter Maydell 2014-02-18 1:14 ` Andreas Färber 0 siblings, 1 reply; 4+ messages in thread From: Peter Maydell @ 2014-02-17 15:18 UTC (permalink / raw) To: Andreas Galauner; +Cc: QEMU Developers On 17 February 2014 14:52, Andreas Galauner <andreas@galauner.de> wrote: > I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the > system using GDB and IDA Pro. The platform is an STM32 and I'm using a > port from github [1] based on qemu 1.5.1 for that. I ported the custom > STM32 code to qemu 1.7.0 to have a more recent version to work with. > > During a debug session, I'm experiencing segfaults in armv7m_nvic.c when > reading the CPUID and Vector base registers (lines 176 and 212), because > ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite > regularly. Debugging with GDB works until you try to read the mentioned > registers by hand like this: > >> (gdb) target remote :1234 >> Remote debugging using :1234 >> 0x08005d1c in ?? () >> (gdb) x/x *0xE000ED00 >> Remote connection closed > > The original STM32-port was based on qemu 1.5.1 and the behaviour was > the same. That was the reason why I ported all that stuff over to 1.7.0 > which unfortunately didn't solve the problem. I don't think I would expect trying to read and write device registers over the gdbstub to work properly -- gdb kind of assumes it's talking to memory, which doesn't have side effects the way devices do. The crash you're running into is caused by the device code assuming that it's only ever accessed by a CPU, not by some other thing like a debugger or DMA access. For the NVIC code in armv7m_nvic.c we know that a v7M CPU has only one core, so you should just be able to replace the uses of "current_cpu" with "first_cpu". Other places which use current_cpu (such as the GIC proper) might be shared with configurations which do have multiple cores and so really do need current_cpu. thanks -- PMM ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults 2014-02-17 15:18 ` Peter Maydell @ 2014-02-18 1:14 ` Andreas Färber 2014-02-18 9:51 ` Peter Maydell 0 siblings, 1 reply; 4+ messages in thread From: Andreas Färber @ 2014-02-18 1:14 UTC (permalink / raw) To: Peter Maydell, Andreas Galauner, Edgar E. Iglesias Cc: Paolo Bonzini, QEMU Developers Am 17.02.2014 16:18, schrieb Peter Maydell: > On 17 February 2014 14:52, Andreas Galauner <andreas@galauner.de> wrote: >> I'm currently trying to emulate an ARM Cortex-M3 and I need to debug the >> system using GDB and IDA Pro. The platform is an STM32 and I'm using a >> port from github [1] based on qemu 1.5.1 for that. I ported the custom >> STM32 code to qemu 1.7.0 to have a more recent version to work with. >> >> During a debug session, I'm experiencing segfaults in armv7m_nvic.c when >> reading the CPUID and Vector base registers (lines 176 and 212), because >> ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quite >> regularly. Debugging with GDB works until you try to read the mentioned >> registers by hand like this: >> >>> (gdb) target remote :1234 >>> Remote debugging using :1234 >>> 0x08005d1c in ?? () >>> (gdb) x/x *0xE000ED00 >>> Remote connection closed [...] > The crash you're running into is caused by the device code assuming > that it's only ever accessed by a CPU, not by some other thing like > a debugger or DMA access. For the NVIC code in armv7m_nvic.c we > know that a v7M CPU has only one core, so you should just be able > to replace the uses of "current_cpu" with "first_cpu". Other > places which use current_cpu (such as the GIC proper) might be > shared with configurations which do have multiple cores and so > really do need current_cpu. While first_cpu may help Andreas in his local copy for STM32, that assumption is not okay in general. The Vybrid VF6 has both a GIC and an NVIC, so our NVIC code should not make assumptions which CPU it can access. I assume we would shield both using CPU address spaces, but I wonder if either of you two has already thought about how those will interact for gdbstub? I remember there being two CPU variables in gdbstub, maybe Andreas can use them to temporarily set current_cpu? Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults 2014-02-18 1:14 ` Andreas Färber @ 2014-02-18 9:51 ` Peter Maydell 0 siblings, 0 replies; 4+ messages in thread From: Peter Maydell @ 2014-02-18 9:51 UTC (permalink / raw) To: Andreas Färber Cc: Edgar E. Iglesias, Andreas Galauner, QEMU Developers, Paolo Bonzini On 18 February 2014 01:14, Andreas Färber <afaerber@suse.de> wrote: > While first_cpu may help Andreas in his local copy for STM32, that > assumption is not okay in general. The Vybrid VF6 has both a GIC and an > NVIC, so our NVIC code should not make assumptions which CPU it can > access. Do you mean it has an M core CPU with an NVIC plus some other A-class CPU with a GIC. Certainly in a system with heterogenous CPUs this change won't work, but we don't support that at all currently and there's a lot of work between here and there. > I assume we would shield both using CPU address spaces The GIC needs to know which CPU it's being accessed by. I guess in theory you could have it export N distributor memory regions which were identical apart from making "I assume I'm being accessed by CPU X" assumptions, but that seems like a bit of a kludge. Ideally we should have some way for the target of a memory transaction to get at information about the source (ie all the out of band info that hardware sends like master ID, privilege level, secure vs nonsecure, etc). > but I > wonder if either of you two has already thought about how those will > interact for gdbstub? I'd need to look at the protocol to figure out if gdbstub does memory accesses in the context of a particular thread (CPU for us) or not. If not, that could be awkward. thanks -- PMM ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-02-18 9:52 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-02-17 14:52 [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults Andreas Galauner 2014-02-17 15:18 ` Peter Maydell 2014-02-18 1:14 ` Andreas Färber 2014-02-18 9:51 ` Peter Maydell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.