From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Iyizn-0008KE-Hp
	for qemu-devel@nongnu.org; Sun, 02 Dec 2007 02:12:07 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Iyizm-0008K2-1O
	for qemu-devel@nongnu.org; Sun, 02 Dec 2007 02:12:06 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Iyizl-0008Jz-S5
	for qemu-devel@nongnu.org; Sun, 02 Dec 2007 02:12:05 -0500
Received: from relay01.mx.bawue.net ([193.7.176.67])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <ths@networkno.de>) id 1Iyizl-0007EJ-6Q
	for qemu-devel@nongnu.org; Sun, 02 Dec 2007 02:12:05 -0500
Date: Sun, 2 Dec 2007 07:12:00 +0000
From: Thiemo Seufer <ths@networkno.de>
Subject: Re: [Qemu-devel] fstat bug on armeb stll exists!
Message-ID: <20071202071200.GC617@networkno.de>
References: <474EC207.1030700@evidence.eu.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <474EC207.1030700@evidence.eu.com>
Reply-To: qemu-devel@nongnu.org
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.gnu.org/pipermail/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: Claudio Scordino <claudio@evidence.eu.com>
Cc: michael trimarchi <michael@evidence.eu.com>, qemu-devel@nongnu.org

Claudio Scordino wrote:
> Hi all,
>
>   more than one year ago we sent a patch on this mailing list to fix a 
> problem of the fstat syscall for armeb. See
>
> http://lists.gnu.org/archive/html/qemu-devel/2006-09/msg00137.html
>
> We found the bug compiling a Linux kernel for armeb on scratchbox.
>
> Qemu seemed to ignore the fact that in big endian systems the fields
> st_blocks and its padding are swapped (to allow future expansion of the 
> field,) so the fix consisted only in swapping the two fields (only in big 
> endian systems, of course).
>
> The patch just changed  qemu/linux-user/syscall_defs.h to
>
> #ifndef TARGET_WORDS_BIGENDIAN
>        target_ulong    st_blocks;
>        target_ulong    __pad4;
> #else
>       target_ulong    __pad4;
>       target_ulong    st_blocks;
> #endif

AFAICS this assumption matches neither the glibc 2.6 nor the Linux
2.6.23 definitions. There is, however, an endianness difference in
handling the st_dev and st_rdev fields which is not handled properly
in QEMU.

I think this needs a separate struct stat definition for (non-EABI)
big endian ARM.


Thiemo