From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKVEO-0005Rc-Gt for qemu-devel@nongnu.org; Tue, 26 Mar 2013 10:52:13 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UKVEK-0001bD-Vd for qemu-devel@nongnu.org; Tue, 26 Mar 2013 10:52:08 -0400 Received: from mail-la0-x22a.google.com ([2a00:1450:4010:c03::22a]:55870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UKVEK-0001aG-OC for qemu-devel@nongnu.org; Tue, 26 Mar 2013 10:52:04 -0400 Received: by mail-la0-f42.google.com with SMTP id fe20so13788554lab.15 for ; Tue, 26 Mar 2013 07:52:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <5151B249.6050602@suse.de> References: <1364300401-9340-1-git-send-email-peter.maydell@linaro.org> <5151B249.6050602@suse.de> From: Peter Maydell Date: Tue, 26 Mar 2013 14:44:42 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] sh7750: Fix crash when accessing PVR/PRR/CVR List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?Q?Andreas_F=C3=A4rber?= Cc: qemu-devel@nongnu.org, patches@linaro.org On 26 March 2013 14:35, Andreas F=C3=A4rber wrote: > Am 26.03.2013 13:20, schrieb Peter Maydell: >> Commit b350ab75 causes segfaults on accesses to PVR/PRR/CVR because >> it tries to call SUPERH_CPU_GET_CLASS() on a pointer that isn't a >> QOM object. Fix this by getting the actual QOM CPU object first. >> >> Signed-off-by: Peter Maydell >> --- >> Tested with the r2d image/instructions from >> https://oss.renesas.com/modules/document/?Getting%20Started%20with%20SH4= %20and%20QEMU > > Oops, reproduces with the test image from the QEMU Wiki as well. Seems > to be a result of cherry-picking this commit before the full SH7750 > QOM'ification. > > Is this blocking any work of yours? Otherwise I would try rebasing my > SH7750 patches so that s->cpu becomes a SuperHCPU as expected here. > (Not sure if simply reverting my offending patch still works?) Well, I have a workaround so it doesn't affect me now :-) I wasn't really doing anything much with the sh4 board, I was just looking at whether we could get rid of its use of taddr properties. (Oddly it uses qdev_prop_set_taddr() to set a property which isn't defined as a TADDR property, but this works anyway...) -- PMM