qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults


From: Andreas Färber
Subject: Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults
Date: Tue, 18 Feb 2014 02:14:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

Am 17.02.2014 16:18, schrieb Peter Maydell:
> On 17 February 2014 14:52, Andreas Galauner <address@hidden> 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



reply via email to

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