From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51175) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQabZ-0002UJ-Tl for qemu-devel@nongnu.org; Wed, 25 Feb 2015 06:58:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQabV-00022z-FK for qemu-devel@nongnu.org; Wed, 25 Feb 2015 06:58:17 -0500 Date: Wed, 25 Feb 2015 12:58:01 +0100 (CET) From: Laurent Vivier Message-ID: <804024825.883.1424865482284.JavaMail.open-xchange@oxbsltgw40.schlund.de> In-Reply-To: References: <1424814498-6993-1-git-send-email-mdroth@linux.vnet.ibm.com> <1424814498-6993-30-git-send-email-mdroth@linux.vnet.ibm.com> <1414725099.11975.1424853577110.JavaMail.open-xchange@oxbsltgw39.schlund.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_882_172874825.1424865481877" Subject: Re: [Qemu-devel] [PATCH 29/43] linux-user: Fix broken m68k signal handling on 64 bit hosts Reply-To: Laurent Vivier List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Michael Roth , Riku Voipio , QEMU Developers , qemu-stable ------=_Part_882_172874825.1424865481877 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > Le 25 f=C3=A9vrier 2015 =C3=A0 12:28, Peter Maydell a =C3=A9crit : > > > On 25 February 2015 at 17:39, Laurent Vivier wrote: > > Hi, > > > > I think you should use abi_long instead of uint32_t. > > > > abi_long has an "aligned" attribute, and on m68k long are aligned on a = short > > boundary. > > > > > > #ifdef TARGET_M68K > > #define ABI_INT_ALIGNMENT 2 > > #define ABI_LONG_ALIGNMENT 2 > > #define ABI_LLONG_ALIGNMENT 2 > > #endif > > > > typedef uint32_t abi_ulong __attribute__((aligned(ABI_LONG_ALIGNMENT)))= ; > > In this instance it doesn't matter because get_sigframe() aligns > the pointer we're going to write the sigframe to, and the elements > in the struct before retcode[] won't make it worse than 4-aligned, > I think? Yes, I agree. But the aim of the abi_* types is to define the target ABI. T= hus, for consistency it should better to use the abi_long (or abi_ulong) instead= of uint32_t. =20 Regards, Laurent ------=_Part_882_172874825.1424865481877 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

> Le 25 février 2015 à 12:28, Peter Maydell <peter.maydell@linaro.org> a écrit :
>
>
> On 25 February 2015 at 17:39, Laurent Vivier <laurent@vivier.eu> wrote:
> > Hi,
> >
> > I think you should use abi_long instead of uint32_t.
> >
> > abi_long has an "aligned" attribute, and on m68k long are aligned on a short
> > boundary.
> >
> >
> > #ifdef TARGET_M68K
> > #define ABI_INT_ALIGNMENT 2
> > #define ABI_LONG_ALIGNMENT 2
> > #define ABI_LLONG_ALIGNMENT 2
> > #endif
> >
> > typedef uint32_t abi_ulong __attribute__((aligned(ABI_LONG_ALIGNMENT)));
>
> In this instance it doesn't matter because get_sigframe() aligns
> the pointer we're going to write the sigframe to, and the elements
> in the struct before retcode[] won't make it worse than 4-aligned,
> I think?

Yes, I agree. But the aim of the abi_* types is to define the target ABI. Thus, for consistency it should better to use the abi_long (or abi_ulong) instead of uint32_t.
 
Regards,
Laurent
------=_Part_882_172874825.1424865481877--