From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60071) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFZH8-0004IW-QX for qemu-devel@nongnu.org; Mon, 17 Feb 2014 20:15:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WFZH2-00073b-RC for qemu-devel@nongnu.org; Mon, 17 Feb 2014 20:15:06 -0500 Received: from cantor2.suse.de ([195.135.220.15]:43751 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WFZH2-00073X-KZ for qemu-devel@nongnu.org; Mon, 17 Feb 2014 20:15:00 -0500 Message-ID: <5302B40F.5090009@suse.de> Date: Tue, 18 Feb 2014 02:14:55 +0100 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <53022228.3000201@galauner.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Cortex-M3: reading NVIC registers causes segfaults List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 wrote= : >> I'm currently trying to emulate an ARM Cortex-M3 and I need to debug t= he >> 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 wh= en >> reading the CPUID and Vector base registers (lines 176 and 212), becau= se >> ARM_CPU(current_cpu) returns a NULL-pointer. IDA seems to do that quit= e >> regularly. Debugging with GDB works until you try to read the mentione= d >> 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 --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg