From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 2q5ZA9rcj2qEQwUAWB0awg (envelope-from ) for ; Thu, 27 Aug 2026 02:44:42 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=Ldjg4Fsb; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id EB9B61E0A3; Thu, 27 Aug 2026 02:44:41 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,WEIRD_PORT autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B17061E09B for ; Thu, 27 Aug 2026 02:44:39 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 64F084BA7997 for ; Thu, 27 Aug 2026 06:44:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64F084BA7997 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=Ldjg4Fsb Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id C1A2C4BA2E39 for ; Thu, 27 Aug 2026 06:44:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C1A2C4BA2E39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C1A2C4BA2E39 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787813043; cv=none; b=AzNAyTUy4PO+KkcPyxejyiWPzvXs0p3TSsO1ANNCcQCkcxnUp0/ZOQ17VdIoNPZW2w49mq9pL63dMeX5Rqz0ea0Wnpt7TgYh+HRyHA8T7vf7gIs+8M4aUPg/W8B4H7s2l5ppXNKSARFmaLP0uAnoB+4yZrua2CY6NWPbGkJoWQE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1787813043; c=relaxed/simple; bh=MZXe5/7RGSnuSvjUDbTS/8Gsw58gv2rWSCvfbkjboNY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=MYv8JzFncUZzfbUAfIEzQj2oaCH6/X76demnCPOEv9V6Vo0WYBZuahc8XofLS6DSFxhh0v6NjNryQrgJhCAkpCX6QiEqkbxqkiPe8VRVGHIJIzUWhqtuZrlp9GnLGomteARRP2avienixg7B7qni8z4W1UhYvQ2rxnncH9jyuBg= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=Ldjg4Fsb DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C1A2C4BA2E39 Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 67R6VdQG2210174; Thu, 27 Aug 2026 06:43:58 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=d7KTEAO6Cyy43UkZwqSp1WcP1X6rbw YBogg1eHooFEs=; b=Ldjg4FsbX7PKnys2NT71DjRm+aii9fJ0FcCLmUg8R/C8wF TFUYDue6VDqCleKRrDYuAckT6HpOWc2vPJrFM6ce0PDvWxxtDK5e6gMMPFutbLhN 02chpexTVq6T8qzo6q/F/ffHjgGEuuoY6zxTto1bmJqHKKME0uQdn5qPHbry2jfw 4mGWmY+1yr5U1dFe+ndbfjozpfhwjQ2PuyqET93Fx545lM+3M6hJcS79GLYDhxir Idq9kPnBRHlodZFqHzh44f3YX8Vtzl82PuYFNTsAUTU5wEdHx/kYfsvE13WUBLik YvNZbQLEYdHd638ffBDdK7NnLrSimqpkifYkiCSA== Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4g73g53qtw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 06:43:58 +0000 (GMT) Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 67R6fGkC030724; Thu, 27 Aug 2026 06:43:57 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([172.16.1.69]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 4g7q3k6j7a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Aug 2026 06:43:57 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (smtpav05.wdc07v.mail.ibm.com [10.39.53.232]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 67R6hs2b20709940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 27 Aug 2026 06:43:54 GMT Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B14C05805D; Thu, 27 Aug 2026 06:43:54 +0000 (GMT) Received: from smtpav05.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 573CE58043; Thu, 27 Aug 2026 06:43:52 +0000 (GMT) Received: from [9.39.23.22] (unknown [9.39.23.22]) by smtpav05.wdc07v.mail.ibm.com (Postfix) with ESMTP; Thu, 27 Aug 2026 06:43:51 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------WCuZ0GLi0LGXCqBgl45JwNQi" Message-ID: Date: Thu, 27 Aug 2026 12:13:50 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: remote fileio: st_ino truncated to 32 bits in vFile:stat/lstat To: Andrew Burgess , "gdb-patches@sourceware.org" Cc: Carl Love , Abhay Kandpal References: <52636405-75ad-402c-8941-7851b1f2a16e@linux.ibm.com> <87ecfku7am.fsf@redhat.com> From: Abhay Kandpal Content-Language: en-GB In-Reply-To: <87ecfku7am.fsf@redhat.com> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: QwuuTnGObAN2CBU2b-r_QbPaXIIdzGoP X-Proofpoint-Spam-Info: AW1haW4tMjYwODI3MDA1MiBTYWx0ZWRfX2WaNKxr7s6pQ JG6h6ocSZHlm9zjJLhnYZhrnocOnh2ZkE/1fx5cZ8JkObrJYL6Nsy1pgDviiZQ3g4vTxi7wGr9K xKJIjb/U1cHDoUWQRDN5Vji7JOlsjiE= X-Proofpoint-GUID: QwuuTnGObAN2CBU2b-r_QbPaXIIdzGoP X-Authority-Analysis: v=2.4 cv=JZyMa0KV c=1 sm=1 tr=0 ts=6a8fdcae cx=c_pps a=GFwsV6G8L6GxiO2Y/PsHdQ==:117 a=GFwsV6G8L6GxiO2Y/PsHdQ==:17 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=U7nrCbtTmkRpXpFmAIza:22 a=r77TgQKjGQsHNAKrUKIA:9 a=CCpqsmhAAAAA:8 a=VnNF1IyMAAAA:8 a=7_uyh3amEmAWNDwl8cQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=20KFwNOVAAAA:8 a=pcxm_rbWHMym04LwlRMA:9 a=iDn25Uwxziqm9YT7:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=ul9cdbp4aOFLsgKbc677:22 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODI3MDA1MiBTYWx0ZWRfX2RaS/96PEYvh ratUamV5R44wN18cS2LnrGcnyOhgbK0w9SRdsfaNiDAp84x8RVbm5leqT5eRO+8hqIwYRNoQ855 vDVbGTGdyCdQu5lYZwd1JhELDHrpO+5ThuktU9FNHCYjIInW1qiLpE9YJP22DxGZ+dvYpSDx1UW slJ0NULY4NTlG9iOmua3DtN1P7mM75zT7ecb8thbfizw0OSMCeNfUmaYOChjsM1IER9kQ+IVyi2 9NJCORylU1lSXcNqvaorLNh05TWxJm3ZFEBH9cw/1FihZjpsDW5LeIW/Pb3scjOM1x32KixEDy9 N7fN0Us/UCOyRbQOwD92kwVPXBcX+xbu67QEyKQnpiorsa39X9ysyneJkEBFMIsxtt9sL6jLyZy +isAnbSsVu2QW/9DcjztRQ89exArO7A3D7MPKZMTinLn+tSt0/93e5IDdAsBichaKjf3GOw8j1F ril0r3o5HdeJZUwXv/w== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-08-27_03,2026-08-26_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 clxscore=1015 adultscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608270052 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org This is a multi-part message in MIME format. --------------WCuZ0GLi0LGXCqBgl45JwNQi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andrew, Thanks — that all makes sense, and yes, I understand why options 1 and 2 break cross-version communication. I'll go with the negotiated approach. Here is the completed table. The "Actual Size" column is sizeof() of the corresponding struct stat member: | Field Name | Type | Size | Actual | | | | Now | Size | |-------------+-------------+------+--------| | fst_dev | fio_uint_t | 4 | 8 | | fst_ino | fio_uint_t | 4 | 8 | | fst_mode | fio_mode_t | 4 | 4 | | fst_nlink | fio_uint_t | 4 | 8 | | fst_uid | fio_uint_t | 4 | 4 | | fst_gid | fio_uint_t | 4 | 4 | | fst_rdev | fio_uint_t | 4 | 8 | | fst_size | fio_ulong_t | 8 | 8 | | fst_blksize | fio_ulong_t | 8 | 8 | | fst_blocks | fio_ulong_t | 8 | 8 | | fst_atime | fio_time_t | 4 | 8 | | fst_mtime | fio_time_t | 4 | 8 | | fst_ctime | fio_time_t | 4 | 8 | So six fields are too narrow: fst_dev, fst_ino, fst_nlink, fst_rdev and the three timestamps. fst_size, fst_blksize and fst_blocks are already fio_ulong_t. fst_mode, fst_uid and fst_gid are 4 bytes in struct stat as well, so those look correct as they are. I got identical sizes on powerpc64le, powerpc64 big-endian and x86-64, and on both ext4 and xfs, so this appears to come from glibc rather than from the architecture or filesystem. I have not checked a 32-bit build. Whether the truncation is visible depends on how large the filesystem's inode numbers get. Largest inode under /home on the three machines I have: ext4, 2 TB 132907009 passes xfs, 2 TB 3896368632 passes xfs, 86 TB 171801755018 fails The second one is at about 91% of 2^32, so it passes today but would not after the filesystem grew. I'll start on the two-struct approach with qSupported negotiation as you described, converting at the wire boundary in both directions. Thanks, Abhay On 26/08/26 22:51, Andrew Burgess wrote: > Abhay Kandpal writes: > >> Hi Andrew, >> >> I hit a failure in gdb.server/fileio-packets.exp on a machine whose filesystem uses inode numbers above 2^32. >> >> All four stat/lstat checks fail, with every field matching except st_ino: >> >> remote = {..., 'st_ino': 2161233200, ...} >> local = {..., 'st_ino': 122420317488, ...} >> >> 122420317488 = 0x1C80CE9BB0 >> 2161233200 = 0x80CE9BB0 >> >> The field is 4 bytes wide in the protocol struct, while st_ino is 64-bit on Linux: >> >> gdbsupport/fileio.h:130 fio_uint_t fst_ino; >> gdbsupport/fileio.cc:281 host_to_fileio_uint ((long) st->st_ino, fst->fst_ino); >> >> fst_size, fst_blksize and fst_blocks in the same struct already use the 8-byte fio_ulong_t. >> It reproduces on xfs (86 TB, largest inode 171801755018) and passes on ext4 (2 TB, largest inode 132907009), >> so it depends on the filesystem rather than the architecture. >> >> https://sourceware.org/bugzilla/show_bug.cgi?id=34567 >> >> Before writing anything I wanted to ask how you'd prefer this handled. >> >> struct fio_stat is shared between the vFile packets and the older F-packet protocol, >> so widening fst_ino changes the wire layout for both. >> >> I can see three options: >> >> 1. Widen the shared field. > I think this would not be accepted as this would break communication > between different versions of GDB and gdbserver, right? > >> 2. Add a separate wider struct used only by the vFile packets, >> along the lines of your reasoning in c29a37f7417 about those packetsstill being new. > I think only fixing vFile would be a mistake. The 'F' packets are not > an older protocol that has been replaced with vFile. The two systems > offer similar functionality, but in opposite directions. If we're > fixing one direction then we really should fix both. > > In c29a37f7417 I changed the underlying implementation of the 'stat' > packet from using 'lstat' to using 'stat'. The actual on-the-wire bits > didn't change, just what gdbserver did with them. An old GDB can still > talk to a new gdbserver and vice versa. What you're proposing would > break this cross version communication, just like option #1, right? > >> 3. Negotiate the wider format through qSupported. > I think this is the only possible way forward unfortunately. It is > going to be more work, but anything else is going to end up breaking > backward compatibility. > >> The second seems the least disruptive, but I don't have a good sense of who else implements these packets. > That's a huge problem we have. We really have no visibility at all for > how this stuff is used outside the GDB project. We solve this problem > by basically assuming that anything that has been released might be > being used, and so cannot be changed. That's probably not true, but we > just have no way of knowing. > >> Also worth deciding at the same time, if the layout is being revised: >> fst_dev and fst_rdev are fio_uint_t although dev_t is 64-bit, and the three timestamps are 4 bytes. > It sounds like what you're saying is that a whole bunch of fields are > the wrong size. I put together this table: > > | Field Name | Type | Size | Actual | > | | | Now | Size | > |-------------+-------------+------+--------| > | fst_dev | fio_uint_t | 4 | 8 | > | fst_ino | fio_uint_t | 4 | 8 | > | fst_mode | fio_mode_t | 4 | ? | > | fst_nlink | fio_uint_t | 4 | ? | > | fst_uid | fio_uint_t | 4 | ? | > | fst_gid | fio_uint_t | 4 | ? | > | fst_rdev | fio_uint_t | 4 | 8 | > | fst_size | fio_ulong_t | 8 | ? | > | fst_blksize | fio_ulong_t | 8 | ? | > | fst_blocks | fio_ulong_t | 8 | ? | > | fst_atime | fio_time_t | 4 | 8? | > | fst_mtime | fio_time_t | 4 | 8? | > | fst_ctime | fio_time_t | 4 | 8? | > > The 'Size Now' is the current field size in fio_stat, while the 'Actual > Size' is what the fields need to be in order to be correct on your > system. You mention the three timestamps above, but don't say what size > they need to be. I'm assuming 8, but that might not be correct either. > Also there are some fields that you haven't mentioned, maybe they are > all correct, but we should check. > > What I'd suggest is that you finish filling in the above table, then I > think you'll want to have two versions of fio_stat, one with the current > field sizes, and one with the wider field sizes. > > I'd suggest that you update the core throughout to use the struct with > the wider field sizes, but at some point before this struct is sent down > the wire, if the use of the wide struct has not been negotiated, then > you'll need to squeeze the wide struct into the short one, trimming the > fields. I think it's OK to print a warning if non-zero information is > discarded at this point. > > Similarly, when one of these structs is pulled from the wire, if the > incoming packet is the narrow version, I'd expand it into the wide > version. In this way, most GDB/gdbserver code will only need to handle > the version with the wider fields, but the wire protocol remains > unchanged. > > Thanks, > Andrew > --------------WCuZ0GLi0LGXCqBgl45JwNQi Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
Hi Andrew,
Thanks — that all makes sense, and yes, I understand why options 1 and 2 break cross-version communication.
I'll go with the negotiated approach.
Here is the completed table.  The "Actual Size" column is sizeof() of the corresponding struct stat member:
  | Field Name  | Type        | Size | Actual |
  |             |             |  Now | Size   |
  |-------------+-------------+------+--------|
  | fst_dev     | fio_uint_t  |    4 | 8      |
  | fst_ino     | fio_uint_t  |    4 | 8      |
  | fst_mode    | fio_mode_t  |    4 | 4      |
  | fst_nlink   | fio_uint_t  |    4 | 8      |
  | fst_uid     | fio_uint_t  |    4 | 4      |
  | fst_gid     | fio_uint_t  |    4 | 4      |
  | fst_rdev    | fio_uint_t  |    4 | 8      |
  | fst_size    | fio_ulong_t |    8 | 8      |
  | fst_blksize | fio_ulong_t |    8 | 8      |
  | fst_blocks  | fio_ulong_t |    8 | 8      |
  | fst_atime   | fio_time_t  |    4 | 8      |
  | fst_mtime   | fio_time_t  |    4 | 8      |
  | fst_ctime   | fio_time_t  |    4 | 8      |
So six fields are too narrow: fst_dev, fst_ino, fst_nlink, fst_rdev and the three timestamps.
fst_size, fst_blksize and fst_blocks are already fio_ulong_t.
fst_mode, fst_uid and fst_gid are 4 bytes in struct stat as well, so those look correct as they are.
I got identical sizes on powerpc64le, powerpc64 big-endian and x86-64, and on both ext4 and xfs,
so this appears to come from glibc rather than from the architecture or filesystem. 
I have not checked a 32-bit build.
Whether the truncation is visible depends on how large the filesystem's inode numbers get.
Largest inode under /home on the three machines I have:
ext4, 2 TB       132907009    passes
xfs,  2 TB      3896368632    passes
xfs,  86 TB   171801755018    fails
The second one is at about 91% of 2^32, so it passes today but would not after the filesystem grew.
I'll start on the two-struct approach with qSupported negotiation as you described,
converting at the wire boundary in both directions.
Thanks,
Abhay



On 26/08/26 22:51, Andrew Burgess wrote:
Abhay Kandpal <abhay@linux.ibm.com> writes:


Hi Andrew,

I hit a failure in gdb.server/fileio-packets.exp on a machine whose filesystem uses inode numbers above 2^32.

All four stat/lstat checks fail, with every field matching except st_ino:

remote = {..., 'st_ino': 2161233200, ...}
local  = {..., 'st_ino': 122420317488, ...}

122420317488 = 0x1C80CE9BB0
2161233200  =   0x80CE9BB0

The field is 4 bytes wide in the protocol struct, while st_ino is 64-bit on Linux:

gdbsupport/fileio.h:130   fio_uint_t  fst_ino;
gdbsupport/fileio.cc:281  host_to_fileio_uint ((long) st->st_ino, fst->fst_ino);

fst_size, fst_blksize and fst_blocks in the same struct already use the 8-byte fio_ulong_t.
It reproduces on xfs (86 TB, largest inode 171801755018) and passes on ext4 (2 TB, largest inode 132907009),
so it depends on the filesystem rather than the architecture.

https://sourceware.org/bugzilla/show_bug.cgi?id=34567 <https://sourceware.org/bugzilla/show_bug.cgi?id=34567>

Before writing anything I wanted to ask how you'd prefer this handled.

struct fio_stat is shared between the vFile packets and the older F-packet protocol,
so widening fst_ino changes the wire layout for both.

I can see three options:

  1. Widen the shared field.

I think this would not be accepted as this would break communication
between different versions of GDB and gdbserver, right?


  2. Add a separate wider struct used only by the vFile packets,
     along the lines of your reasoning in c29a37f7417 about those packetsstill being new.

I think only fixing vFile would be a mistake.  The 'F' packets are not
an older protocol that has been replaced with vFile.  The two systems
offer similar functionality, but in opposite directions.  If we're
fixing one direction then we really should fix both.

In c29a37f7417 I changed the underlying implementation of the 'stat'
packet from using 'lstat' to using 'stat'.  The actual on-the-wire bits
didn't change, just what gdbserver did with them.  An old GDB can still
talk to a new gdbserver and vice versa.  What you're proposing would
break this cross version communication, just like option #1, right?


  3. Negotiate the wider format through qSupported.

I think this is the only possible way forward unfortunately.  It is
going to be more work, but anything else is going to end up breaking
backward compatibility.


The second seems the least disruptive, but I don't have a good sense of who else implements these packets.

That's a huge problem we have.  We really have no visibility at all for
how this stuff is used outside the GDB project.  We solve this problem
by basically assuming that anything that has been released might be
being used, and so cannot be changed.  That's probably not true, but we
just have no way of knowing.


Also worth deciding at the same time, if the layout is being revised:
fst_dev and fst_rdev are fio_uint_t although dev_t is 64-bit, and the three timestamps are 4 bytes.

It sounds like what you're saying is that a whole bunch of fields are
the wrong size.  I put together this table:

  | Field Name  | Type        | Size | Actual |
  |             |             |  Now | Size   |
  |-------------+-------------+------+--------|
  | fst_dev     | fio_uint_t  |    4 | 8      |
  | fst_ino     | fio_uint_t  |    4 | 8      |
  | fst_mode    | fio_mode_t  |    4 | ?      |
  | fst_nlink   | fio_uint_t  |    4 | ?      |
  | fst_uid     | fio_uint_t  |    4 | ?      |
  | fst_gid     | fio_uint_t  |    4 | ?      |
  | fst_rdev    | fio_uint_t  |    4 | 8      |
  | fst_size    | fio_ulong_t |    8 | ?      |
  | fst_blksize | fio_ulong_t |    8 | ?      |
  | fst_blocks  | fio_ulong_t |    8 | ?      |
  | fst_atime   | fio_time_t  |    4 | 8?     |
  | fst_mtime   | fio_time_t  |    4 | 8?     |
  | fst_ctime   | fio_time_t  |    4 | 8?     |

The 'Size Now' is the current field size in fio_stat, while the 'Actual
Size' is what the fields need to be in order to be correct on your
system.  You mention the three timestamps above, but don't say what size
they need to be.  I'm assuming 8, but that might not be correct either.
Also there are some fields that you haven't mentioned, maybe they are
all correct, but we should check.

What I'd suggest is that you finish filling in the above table, then I
think you'll want to have two versions of fio_stat, one with the current
field sizes, and one with the wider field sizes.

I'd suggest that you update the core throughout to use the struct with
the wider field sizes, but at some point before this struct is sent down
the wire, if the use of the wide struct has not been negotiated, then
you'll need to squeeze the wide struct into the short one, trimming the
fields.  I think it's OK to print a warning if non-zero information is
discarded at this point.

Similarly, when one of these structs is pulled from the wire, if the
incoming packet is the narrow version, I'd expand it into the wide
version.  In this way, most GDB/gdbserver code will only need to handle
the version with the wider fields, but the wire protocol remains
unchanged.

Thanks,
Andrew
--------------WCuZ0GLi0LGXCqBgl45JwNQi--