From: "Andreas Färber" <afaerber@suse.de>
To: Peter Maydell <peter.maydell@linaro.org>,
Andreas Galauner <andreas@galauner.de>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults
Date: Tue, 18 Feb 2014 02:14:55 +0100 [thread overview]
Message-ID: <5302B40F.5090009@suse.de> (raw)
In-Reply-To: <CAFEAcA8MCjehZU4bw7fubCO2ds8YubNg8s1z9cZ0LSQdA=G=Gw@mail.gmail.com>
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
next prev parent reply other threads:[~2014-02-18 1:15 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2014-02-18 9:51 ` Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5302B40F.5090009@suse.de \
--to=afaerber@suse.de \
--cc=andreas@galauner.de \
--cc=edgar.iglesias@gmail.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.