From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=56289 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PkKcc-0007oF-T3
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:06:37 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <blauwirbel@gmail.com>) id 1PkKZ3-00011w-RP
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:02:56 -0500
Received: from mail-px0-f173.google.com ([209.85.212.173]:45623)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <blauwirbel@gmail.com>) id 1PkKZ3-00011j-JG
	for qemu-devel@nongnu.org; Tue, 01 Feb 2011 13:02:53 -0500
Received: by pxi16 with SMTP id 16so1294879pxi.4
	for <qemu-devel@nongnu.org>; Tue, 01 Feb 2011 10:02:52 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <AANLkTi=E0p_Wdd3gRDQisrhqSc=paooBf4b+9m4ZxNQG@mail.gmail.com>
References: <1296575692-23335-1-git-send-email-peter.maydell@linaro.org>
	<AANLkTi=E0p_Wdd3gRDQisrhqSc=paooBf4b+9m4ZxNQG@mail.gmail.com>
From: Blue Swirl <blauwirbel@gmail.com>
Date: Tue, 1 Feb 2011 18:02:32 +0000
Message-ID: <AANLkTik_gGJORqYaeCTs6Mfd+2U40p5ei3DdFHS7r42p@mail.gmail.com>
Subject: Re: [Qemu-devel] [PATCH] linux-user: avoid gcc array overrun warning
	for sparc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Riku Voipio <riku.voipio@iki.fi>, qemu-devel@nongnu.org, patches@linaro.org

On Tue, Feb 1, 2011 at 4:00 PM, Peter Maydell <peter.maydell@linaro.org> wr=
ote:
> On 1 February 2011 15:54, Peter Maydell <peter.maydell@linaro.org> wrote:
>> --- a/linux-user/signal.c
>> +++ b/linux-user/signal.c
>> @@ -1817,9 +1817,10 @@ struct target_sigcontext {
>> =C2=A0/* A Sparc stack frame */
>> =C2=A0struct sparc_stackf {
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 abi_ulong locals[8];
>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0abi_ulong ins[6];
>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0struct sparc_stackf *fp;
>> - =C2=A0 =C2=A0 =C2=A0 =C2=A0abi_ulong callers_pc;
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0abi_ulong ins[8];
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0/* It's simpler to treat fp and callers_pc =
as elements of ins[]
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 * since we never need to access them ourse=
lves.
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 */
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 char *structptr;
>
> Incidentally, I think the presence of a host pointer in a target
> structure definition is a (different) bug which might cause problems
> when the target and host have different pointer sizes...

Right, it was copied from Linux. I can't see where it was used.
UREG_FP use cases look OK.