All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Andreas Galauner <andreas@galauner.de>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults
Date: Mon, 17 Feb 2014 15:18:55 +0000	[thread overview]
Message-ID: <CAFEAcA8MCjehZU4bw7fubCO2ds8YubNg8s1z9cZ0LSQdA=G=Gw@mail.gmail.com> (raw)
In-Reply-To: <53022228.3000201@galauner.de>

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

  reply	other threads:[~2014-02-17 15:19 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 [this message]
2014-02-18  1:14   ` Andreas Färber
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='CAFEAcA8MCjehZU4bw7fubCO2ds8YubNg8s1z9cZ0LSQdA=G=Gw@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=andreas@galauner.de \
    --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.