From: Luca Bonissi <qemu@bonslack.org>
To: Thomas Huth <thuth@redhat.com>,
qemu-devel@nongnu.org, Laurent Vivier <laurent@vivier.eu>
Subject: Re: stat64 wrong on sparc64 user
Date: Tue, 28 Mar 2023 14:22:29 +0200 [thread overview]
Message-ID: <d49d441a-01a6-d38d-2bc8-98b9658a288e@bonslack.org> (raw)
In-Reply-To: <bdebe626-e552-affb-b756-02c70898bdd6@redhat.com>
On 28/03/23 13:55, Thomas Huth wrote:
> On 28/03/2023 13.48, Luca Bonissi wrote:
>> --- qemu-20230327/linux-user/syscall_defs.h 2023-03-27
>> 15:41:42.000000000 +0200
>> +++ qemu-20230327/linux-user/syscall_defs.h.new 2023-03-27
>> 21:43:25.615115126 +0200
>> @@ -1450,7 +1450,7 @@ struct target_stat {
>> unsigned int st_dev;
>> abi_ulong st_ino;
>> unsigned int st_mode;
>> - unsigned int st_nlink;
>> + short int st_nlink;
>> unsigned int st_uid;
>
> That looks wrong at a first glance. IIRC Sparc is a very strictly
> aligned architecture, so if the previous field "st_mode" was aligned to
> a 4-byte boundary, the "st_uid" field now would not be aligned
> anymore... are you sure about this change? Maybe it needs a padding
> field now?
The padding is automatic (either on Sparc or x86-64): short will be
aligned to 2-byte boundary, int will be aligned to 4-byte boundary, long
will be aligned to 8-byte boundary.
E.g.:
st_dev=0x05060708;
st_ino=0x1112131415161718;
st_mode=0x1a1b1c1d;
st_nlink=0x2728;
st_uid=0x2a2b2c2d;
st_gid=0x3a3b3c3d;
st_rdev=0x35363738;
st_size=0x4142434445464748;
st_blksize=0x5152535455565758;
will result (sparc64 - big endian):
00: 05 06 07 08 00 00 00 00
08: 11 12 13 14 15 16 17 18
10: 1A 1B 1C 1D 27 28 00 00
18: 2A 2B 2C 2D 3A 3B 3C 3D
20: 35 36 37 38 00 00 00 00
28: 41 42 43 44 45 46 47 48
30: 00 00 00 00 00 00 00 00
38: 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00
48: 51 52 53 54 55 56 57 58
50: 00 00 00 00 00 00 00 00
58: 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00
Or on x86-64 (little endian):
00: 08 07 06 05 00 00 00 00
08: 18 17 16 15 14 13 12 11
10: 1D 1C 1B 1A 28 27 00 00
18: 2D 2C 2B 2A 3D 3C 3B 3A
20: 38 37 36 35 00 00 00 00
28: 48 47 46 45 44 43 42 41
30: 00 00 00 00 00 00 00 00
38: 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00
48: 58 57 56 55 54 53 52 51
50: 00 00 00 00 00 00 00 00
58: 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00
Please note the automatic padding between "st_dev" and "st_ino" (offset
0x04, 4 bytes), "st_nlink" and "st_uid" (offset 0x16, 2 bytes),
"st_rdev" and "st_size" (offset 0x24, 4 bytes).
Placing st_nlink as int would result in incorrect big/little endian
conversion, so it should be set as short. If you like clearer source
code, you can optionally add padding, but it is not mandatory.
Thanks!
Luca
next prev parent reply other threads:[~2023-03-28 12:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-28 11:48 stat64 wrong on sparc64 user Luca Bonissi
2023-03-28 11:55 ` Thomas Huth
2023-03-28 12:22 ` Luca Bonissi [this message]
2023-03-28 12:41 ` Thomas Huth
2023-03-29 16:22 ` Laurent Vivier
2023-03-30 11:13 ` Luca Bonissi
2023-03-28 14:52 ` Richard Henderson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d49d441a-01a6-d38d-2bc8-98b9658a288e@bonslack.org \
--to=qemu@bonslack.org \
--cc=laurent@vivier.eu \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).