From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YzjoBMBjmmrqrycAWB0awg (envelope-from ) for ; Fri, 04 Sep 2026 02:22:56 -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=fSoXSn2H; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id CFADE1E166; Fri, 04 Sep 2026 02:22:55 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.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 9D16E1E09B for ; Fri, 04 Sep 2026 02:22:53 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AD3EA4BB3B87 for ; Fri, 4 Sep 2026 06:22:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD3EA4BB3B87 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=fSoXSn2H Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 14ED74BB1C3D for ; Fri, 4 Sep 2026 06:22:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 14ED74BB1C3D 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 14ED74BB1C3D 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=1788502944; cv=none; b=scV/7orGpQjmUa9T2mzgdSRfBA0OFWp+ebu8xWMwUzW1VUcsNaYcWuMcE7r7XncYRxR73UB6yldR/xhxb5IhWCQXOVmHW8UzjFT/ITLkqKofkbw9t5gIYEXst0uBiE0xPpppDJJ+eQCDl/xoXZrvE03dp+ERXjZPTkCXJjgTAcQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788502944; c=relaxed/simple; bh=wq1c5Lqn5cf3HgYom3r75yXM0JMzHo4VPp8rGH0Ugbk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=RE46tPefgl2UqUchjDDAlc9p5OY7nHPtAmqsrROeGTVFSb5TNNxBc10L+q8pxUnUn4skjXJjzHropNMJf9NLVONY88/ruIIBHqgj4WT/yLLWhHX4VUknEoqcuj4Jv47hbwdCxy0599YHt4+zAUl7F7T8WArAldNts++ZZZ03/WU= 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=fSoXSn2H DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 14ED74BB1C3D Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68464O9C936926; Fri, 4 Sep 2026 06:22:14 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=IUtJbw4LPIW2yvyjSYwGjegvUL/6C1 EcZpZNzkEo5Uc=; b=fSoXSn2HsNPQJLGs+FAiP4dNPlHxYq5JFtHv9WQ6cIXLpE LxHiYEmxgIYA59Mb7YdbJhGDQ3cWuFBQ9R1IcIY0ouLXUVIwkgJjFxWPb+9I4CXk iyZlCezKSLdgkU08+VeIktJp2Rzi0ezlSx/qaVgY+5mMIX65CvpS8gF0PSSzMjAM KsoQvoK7xThiqWAfjWepyKdUbiFn7fTvUE7RofVHD6FmC+OHnSKkpTOnsl/rHKW9 hmBAQWAq46o/Hs3W4so/S0q6eDRQyM5uCcuiQZFNFA2xTJz2d04KdWxdpHG6E63w UU0JMamfe8571gPxXyPqjyUBGnwU9C3kSAZeAaxQ== Received: from ppma11.dal12v.mail.ibm.com (db.9e.1632.ip4.static.sl-reverse.com [50.22.158.219]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gbpx612s7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Sep 2026 06:22:14 +0000 (GMT) Received: from pps.filterd (ppma11.dal12v.mail.ibm.com [127.0.0.1]) by ppma11.dal12v.mail.ibm.com (8.18.1.7/8.18.1.7) with ESMTP id 6846Bj90026568; Fri, 4 Sep 2026 06:22:13 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma11.dal12v.mail.ibm.com (PPS) with ESMTPS id 4gcceykb9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Sep 2026 06:22:13 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 6846M9c817564380 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 4 Sep 2026 06:22:10 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D488358055; Fri, 4 Sep 2026 06:22:09 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C985158043; Fri, 4 Sep 2026 06:22:07 +0000 (GMT) Received: from [9.127.57.139] (unknown [9.127.57.139]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTP; Fri, 4 Sep 2026 06:22:07 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------VZQazqAptBDHuIStWZmTJisL" Message-ID: <84e01be2-82cd-4007-86e2-4b4462ecb66c@linux.ibm.com> Date: Fri, 4 Sep 2026 11:52:06 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1] gdbserver: widen the stat fields returned by the vFile packets To: Eli Zaretskii Cc: gdb-patches@sourceware.org, aburgess@redhat.com, cel@linux.ibm.com, abhay.k@ibm.com References: <20260903140555.1181769-1-abhay@linux.ibm.com> <8633vq495w.fsf@gnu.org> From: Abhay Kandpal Content-Language: en-GB In-Reply-To: <8633vq495w.fsf@gnu.org> X-TM-AS-GCONF: 00 X-Authority-Analysis: v=2.4 cv=PPc/P/qC c=1 sm=1 tr=0 ts=6a9a6396 cx=c_pps a=aDMHemPKRhS1OARIsFnwRA==:117 a=aDMHemPKRhS1OARIsFnwRA==:17 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=r77TgQKjGQsHNAKrUKIA:9 a=CCpqsmhAAAAA:8 a=VnNF1IyMAAAA:8 a=mDV3o1hIAAAA:8 a=2Bcbl5-ZZTCULcOf-swA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=20KFwNOVAAAA:8 a=aOKeB8NCta6hxWExE44A:9 a=xlxI2J8jlSlysbsT:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=ul9cdbp4aOFLsgKbc677:22 X-Proofpoint-GUID: yZTmDOZiM6RiNHe7CReYKBfL-BSWkhxm X-Proofpoint-ORIG-GUID: yZTmDOZiM6RiNHe7CReYKBfL-BSWkhxm X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA0MDA1NCBTYWx0ZWRfXyHa3YdA7YgDd 70z1qfVsDUelAION6Ui/fb5EiOe1mewl4ZK/gEg4djumFxPbfg8Q8sZNyC4d7/2ymLmJaFgMSek z8Zt/uQhKh58CghwpxiBZUa45Z28wlM= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA0MDA1NCBTYWx0ZWRfX6ppOQdUwOJuE C+GLh+4optKPYfUFMC9dz07SPbgae0DZTpkZBt7BdpTC9kHygLDoUfHQvFOuxLzhsnF4wiBkmxP 5mBpBNInhLocyoMSBe1Y1J7ko7B4icJB6lPahWlnNr9YqJx/SZEna9Abi2vYjGK6XJJ1aFMz4UH y2ebNvZGv2RKHSbKmjkQAz7sP9JPhb+KboFBPoLe9N8xWtdNWP6410BBWNlf9yAwfx6sB3kLF+X bAn7Z5Wp6t+ROlZLxlEwx81XlucQhYj0oozWuUL6PXLCoz4JM8vrnMjR+FWo84zzarOg491EJou 5jK6u5AmM9Skuei9bu0vJFECfnIzcNZLJGdgnH3OCllvXy+6NO7i0KYWJMSWR9/x6NeJymwgSsg D8LlXDKlbb1P7yh065YcZm2WRQRpcdEV+lEyMPkdsFhJIjdnjCotZ+7C/hSHhC8Q7tHD6BNEXK+ 27OwQWcfxL0FtmNOPHw== 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-09-04_02,2026-09-03_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1011 phishscore=0 adultscore=0 suspectscore=0 bulkscore=0 spamscore=0 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609040054 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. --------------VZQazqAptBDHuIStWZmTJisL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Eli, On 03/09/26 21:30, Eli Zaretskii wrote: >> From: Abhay Kandpal >> Cc:aburgess@redhat.com,cel@linux.ibm.com,abhay.k@ibm.com, >> Abhay Kandpal >> Date: Thu, 3 Sep 2026 09:05:55 -0500 >> >> >> gdb/ >> * NEWS: Mention the stat64 feature. >> * doc/gdb.texinfo (General Query Packets): Document the stat64 >> feature. >> (Host I/O Packets): Mention the wide reply format. >> (struct stat64): New node. >> * remote-fileio.c (remote_fileio_to_host_ulong8): New function. >> (remote_fileio_wide_to_host_stat): New function. >> * remote-fileio.h (remote_fileio_wide_to_host_stat): Declare. >> * remote.c (PACKET_stat64_feature): New enum value. >> (remote_features::stat64_feature): New method. >> (remote_protocol_features): Add stat64. >> (remote_target::remote_query_supported): Send stat64+. >> (fileio_process_fstat_and_lstat_reply): Handle both formats. >> (INIT_GDB_FILE): Add the stat64-feature packet command. >> * testsuite/gdb.server/fileio-packets.py (decode_stat_reply): >> Handle both the narrow and wide reply formats. >> >> gdbserver/ >> * hostio.cc (handle_fstat, handle_stat, handle_lstat): Send the >> wide struct when the feature is negotiated. >> * server.cc (handle_query): Handle and report stat64. >> * server.h (client_state::stat64_feature): New member. >> >> gdbsupport/ >> * fileio.cc (host_to_fileio_stat_wide): New function. >> (narrow_field, fileio_stat_wide_to_narrow): New functions. >> * fileio.h (struct fio_stat_wide): New struct. >> (bigendian_to_host): New function. >> (host_to_fileio_stat_wide, fileio_stat_wide_to_narrow): Declare. >> >> Bug:https://sourceware.org/bugzilla/show_bug.cgi?id=34567 >> --- >> This patch is reg tested. >> >> gdb/NEWS | 12 +++ >> gdb/doc/gdb.texinfo | 49 ++++++++++ >> gdb/remote-fileio.c | 35 ++++++- >> gdb/remote-fileio.h | 4 + >> gdb/remote.c | 36 +++++-- >> gdb/testsuite/gdb.server/fileio-packets.py | 59 +++++++----- >> gdbserver/hostio.cc | 106 +++++++++++++++------ >> gdbserver/server.cc | 4 +- >> gdbserver/server.h | 5 + >> gdbsupport/fileio.cc | 70 ++++++++++++++ >> gdbsupport/fileio.h | 54 ++++++++++- >> 11 files changed, 368 insertions(+), 66 deletions(-) >> >> diff --git a/gdb/NEWS b/gdb/NEWS >> index 222f38e3d52..de8346350ab 100644 >> --- a/gdb/NEWS >> +++ b/gdb/NEWS >> @@ -3,6 +3,18 @@ >> >> *** Changes since GDB 18 >> >> +* Changed remote packets >> + >> +stat64 in qSupported >> + >> + The new stat64 feature within the qSupported packet allows GDB and >> + the stub to agree on a wider form of the stat structure returned by >> + the vFile:fstat, vFile:stat and vFile:lstat packets, in which st_dev, >> + st_ino, st_nlink, st_rdev and the three timestamps are 8 bytes rather >> + than 4. The wider form is used only when both sides report the >> + feature; otherwise the existing format is used and values which do >> + not fit are truncated as before. > This is okay, but does it mean that 32-bit timestamps mean that > version will die after 2038? If so, perhaps this should be mentioned > in the NEWS entry? It's 2106 rather than 2038. The narrow field is read as unsigned: remote_fileio_to_host_time calls remote_fileio_to_host_uint, which uses extract_unsigned_integer, so the range is 0 to 4294967295 seconds from the epoch. I'll mention this in the NEWS entry. > >> +@item stat64 >> +The remote stub supports the wider form of the stat structure returned >> +by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat} >> +packets, as described in @ref{struct stat64}. > The "as described in @ref..." paradigm produces nice HTML, but looks > awkward in Info, because it produces "see". I suggest a more > traditional > > ...by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat} > packets (@pxref{stat64}). Will fix, here and at the other five places. My node is named "struct stat64" (to match the existing "struct stat" node), so I'll use @pxref{struct stat64} — let me know if you'd prefer the node renamed. > >> +If both @value{GDBN} and the stub report the @samp{stat64} feature in >> +the @samp{qSupported} exchange, the wider format described in >> +@ref{struct stat64} is used instead. > Same here. > >> +If both @value{GDBN} and the stub report the @samp{stat64} feature in >> +the @samp{qSupported} exchange, the wider format described in >> +@ref{struct stat64} is used instead. > And here. > >> +If both @value{GDBN} and the stub report the @samp{stat64} feature in >> +the @samp{qSupported} exchange, the wider format described in >> +@ref{struct stat64} is used instead. > And here. > >> +When the @samp{stat64} feature has been negotiated, the buffer returned >> +by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat} >> +packets uses the following representation instead: >> + >> +@smallexample >> +struct stat64 @{ >> + unsigned long st_dev; /* device */ >> + unsigned long st_ino; /* inode */ >> + mode_t st_mode; /* protection */ >> + unsigned long st_nlink; /* number of hard links */ >> + unsigned int st_uid; /* user ID of owner */ >> + unsigned int st_gid; /* group ID of owner */ >> + unsigned long st_rdev; /* device type (if inode device) */ >> + unsigned long st_size; /* total size, in bytes */ >> + unsigned long st_blksize; /* blocksize for filesystem I/O */ >> + unsigned long st_blocks; /* number of blocks allocated */ >> + unsigned long st_atime; /* time of last access */ >> + unsigned long st_mtime; /* time of last modification */ >> + unsigned long st_ctime; /* time of last change */ >> +@}; >> +@end smallexample > You probably assumed that 'unsigned long' is a 64-bit type. But that > is not always true, so I suggest to use a more explicit uint64_t type > instead. Good catch - I'd copied the types from the existing struct stat documentation without thinking about it. Will use uint64_t. Thanks for the review. I'll send a v2 soon. Abhay > >> +This structure is of size 92 bytes. The fields have the same meanings >> +as in @ref{struct stat}, but @code{st_dev}, @code{st_ino}, > The "in @ref..." issue again. > >> +This representation is only used by the @samp{vFile} packets; the >> +File-I/O protocol always uses @ref{struct stat}. > And here. > > Thanks. > > Reviewed-By: Eli Zaretskii --------------VZQazqAptBDHuIStWZmTJisL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
Hi Eli,
On 03/09/26 21:30, Eli Zaretskii wrote:
From: Abhay Kandpal <abhay@linux.ibm.com>
Cc: aburgess@redhat.com, cel@linux.ibm.com, abhay.k@ibm.com,
 Abhay Kandpal <abhay@linux.ibm.com>
Date: Thu,  3 Sep 2026 09:05:55 -0500


gdb/
	* NEWS: Mention the stat64 feature.
	* doc/gdb.texinfo (General Query Packets): Document the stat64
	feature.
	(Host I/O Packets): Mention the wide reply format.
	(struct stat64): New node.
	* remote-fileio.c (remote_fileio_to_host_ulong8): New function.
	(remote_fileio_wide_to_host_stat): New function.
	* remote-fileio.h (remote_fileio_wide_to_host_stat): Declare.
	* remote.c (PACKET_stat64_feature): New enum value.
	(remote_features::stat64_feature): New method.
	(remote_protocol_features): Add stat64.
	(remote_target::remote_query_supported): Send stat64+.
	(fileio_process_fstat_and_lstat_reply): Handle both formats.
	(INIT_GDB_FILE): Add the stat64-feature packet command.
	* testsuite/gdb.server/fileio-packets.py (decode_stat_reply):
	Handle both the narrow and wide reply formats.

gdbserver/
	* hostio.cc (handle_fstat, handle_stat, handle_lstat): Send the
	wide struct when the feature is negotiated.
	* server.cc (handle_query): Handle and report stat64.
	* server.h (client_state::stat64_feature): New member.

gdbsupport/
	* fileio.cc (host_to_fileio_stat_wide): New function.
	(narrow_field, fileio_stat_wide_to_narrow): New functions.
	* fileio.h (struct fio_stat_wide): New struct.
	(bigendian_to_host): New function.
	(host_to_fileio_stat_wide, fileio_stat_wide_to_narrow): Declare.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34567
---
This patch is reg tested.

 gdb/NEWS                                   |  12 +++
 gdb/doc/gdb.texinfo                        |  49 ++++++++++
 gdb/remote-fileio.c                        |  35 ++++++-
 gdb/remote-fileio.h                        |   4 +
 gdb/remote.c                               |  36 +++++--
 gdb/testsuite/gdb.server/fileio-packets.py |  59 +++++++-----
 gdbserver/hostio.cc                        | 106 +++++++++++++++------
 gdbserver/server.cc                        |   4 +-
 gdbserver/server.h                         |   5 +
 gdbsupport/fileio.cc                       |  70 ++++++++++++++
 gdbsupport/fileio.h                        |  54 ++++++++++-
 11 files changed, 368 insertions(+), 66 deletions(-)

diff --git a/gdb/NEWS b/gdb/NEWS
index 222f38e3d52..de8346350ab 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -3,6 +3,18 @@
 
 *** Changes since GDB 18
 
+* Changed remote packets
+
+stat64 in qSupported
+
+  The new stat64 feature within the qSupported packet allows GDB and
+  the stub to agree on a wider form of the stat structure returned by
+  the vFile:fstat, vFile:stat and vFile:lstat packets, in which st_dev,
+  st_ino, st_nlink, st_rdev and the three timestamps are 8 bytes rather
+  than 4.  The wider form is used only when both sides report the
+  feature; otherwise the existing format is used and values which do
+  not fit are truncated as before.

This is okay, but does it mean that 32-bit timestamps mean that
version will die after 2038?  If so, perhaps this should be mentioned
in the NEWS entry?
It's 2106 rather than 2038. The narrow field is read as unsigned:
remote_fileio_to_host_time calls remote_fileio_to_host_uint, which uses
extract_unsigned_integer, so the range is 0 to 4294967295 seconds from
the epoch.  I'll mention this in the NEWS entry.


+@item stat64
+The remote stub supports the wider form of the stat structure returned
+by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat}
+packets, as described in @ref{struct stat64}.

The "as described in @ref..." paradigm produces nice HTML, but looks
awkward in Info, because it produces "see".  I suggest a more
traditional

  ...by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat}
  packets (@pxref{stat64}).
Will fix, here and at the other five places.  My node is named
"struct stat64" (to match the existing "struct stat" node), so I'll use
@pxref{struct stat64} — let me know if you'd prefer the node renamed.


+If both @value{GDBN} and the stub report the @samp{stat64} feature in
+the @samp{qSupported} exchange, the wider format described in
+@ref{struct stat64} is used instead.

Same here.


+If both @value{GDBN} and the stub report the @samp{stat64} feature in
+the @samp{qSupported} exchange, the wider format described in
+@ref{struct stat64} is used instead.

And here.


+If both @value{GDBN} and the stub report the @samp{stat64} feature in
+the @samp{qSupported} exchange, the wider format described in
+@ref{struct stat64} is used instead.

And here.


+When the @samp{stat64} feature has been negotiated, the buffer returned
+by the @samp{vFile:fstat}, @samp{vFile:stat} and @samp{vFile:lstat}
+packets uses the following representation instead:
+
+@smallexample
+struct stat64 @{
+    unsigned long st_dev;      /* device */
+    unsigned long st_ino;      /* inode */
+    mode_t        st_mode;     /* protection */
+    unsigned long st_nlink;    /* number of hard links */
+    unsigned int  st_uid;      /* user ID of owner */
+    unsigned int  st_gid;      /* group ID of owner */
+    unsigned long st_rdev;     /* device type (if inode device) */
+    unsigned long st_size;     /* total size, in bytes */
+    unsigned long st_blksize;  /* blocksize for filesystem I/O */
+    unsigned long st_blocks;   /* number of blocks allocated */
+    unsigned long st_atime;    /* time of last access */
+    unsigned long st_mtime;    /* time of last modification */
+    unsigned long st_ctime;    /* time of last change */
+@};
+@end smallexample

You probably assumed that 'unsigned long' is a 64-bit type.  But that
is not always true, so I suggest to use a more explicit uint64_t type
instead.
Good catch - I'd copied the types from the existing struct stat
documentation without thinking about it.  Will use uint64_t.
Thanks for the review.  I'll send a v2 soon.

Abhay


+This structure is of size 92 bytes.  The fields have the same meanings
+as in @ref{struct stat}, but @code{st_dev}, @code{st_ino},

The "in @ref..." issue again.


+This representation is only used by the @samp{vFile} packets; the
+File-I/O protocol always uses @ref{struct stat}.

And here.

Thanks.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
--------------VZQazqAptBDHuIStWZmTJisL--