From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SWy8B8CZmWpxxiUAWB0awg (envelope-from ) for ; Thu, 03 Sep 2026 12:01:04 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Oockgm0G; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 180951E166; Thu, 03 Sep 2026 12:01:04 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 0EA2E1E033 for ; Thu, 03 Sep 2026 12:01:03 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5C5CA4B99F76 for ; Thu, 3 Sep 2026 16:01:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C5CA4B99F76 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Oockgm0G Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id D10174BA9036 for ; Thu, 3 Sep 2026 16:00:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D10174BA9036 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D10174BA9036 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2001:470:142:3::10 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788451235; cv=none; b=Mwxgp/XpObOBOg9phVAdPF3PPm9lIh3kcf3U4g/jxCHMr96fxAdnAFvISiY+NLCdINFRCyAngjvYAKNvD16pi+DWUubGSPBRs37rdO4hZVG6gTyVYWIcYqC+c3bmFufA2V1uaD3C98MJo5v7aQSo9B5dTYPokwUWU9XBXC4E/DE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1788451235; c=relaxed/simple; bh=WDesGl002QZ3OYOqzDkX6g2mWCWQfxz6TsOJtnjqu44=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=KsESC1FOykv+IskvIhKuYYlSHEt8OGuNMoeO6LfxHuPNRgbRNCMHFjJ0YkqWMR3Uws37V4AbqQMMZgNoaz2c+WqZpX1CFHoll6ibqDpHMcUlsrrU41SPzVlaup4kgz6cIqp0RRvnhuJ8j5jJlluNK5jKM6hDmnBmVZl4HrUKooE= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=Oockgm0G DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D10174BA9036 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1x29rb-0007Kh-0L; Thu, 03 Sep 2026 12:00:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2NDJOk4jOhh52pbEDkM4daZi/mKK1v15mLFY7RpKezg=; b=Oockgm0GPFvg whbdjT0gqEZg12AkFD4tPNbOBPzkU2Bh5xjlo3B5/W6FXjfr9BOeoLlKx4QN7qwC/qCZDB915N4Ur 6zlSbEIcYPfH9Z3hxekQOVCjnV63YffKTDF4zAqTFLcHxfR8ZLmMm+sgoT6gyQrSKR97cSPwm1f6s BPVsN3r3HclM4kjgzkTtoaWNkD40BRIQS6KOwDJjApyyqGBog9gSRAcU7L+JzLCz/rQDCM5SkpJqV IIEc9PoBWYVzmWxoUMXz5qrU6y1mWppHWxCP7FUdh7hAo/gwBUgs0DyAlQ9o5+SgruSk14UUF5q55 CquL59ABoNzkzjyPDtPdpg==; Date: Thu, 03 Sep 2026 19:00:27 +0300 Message-Id: <8633vq495w.fsf@gnu.org> From: Eli Zaretskii To: Abhay Kandpal Cc: gdb-patches@sourceware.org, aburgess@redhat.com, cel@linux.ibm.com, abhay.k@ibm.com In-Reply-To: <20260903140555.1181769-1-abhay@linux.ibm.com> (message from Abhay Kandpal on Thu, 3 Sep 2026 09:05:55 -0500) Subject: Re: [PATCH v1] gdbserver: widen the stat fields returned by the vFile packets References: <20260903140555.1181769-1-abhay@linux.ibm.com> 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 > 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? > +@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}). > +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. > +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