From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yfhtNpjX4Wql3DwAWB0awg (envelope-from ) for ; Wed, 28 Oct 2026 07:08:08 -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=HSfy4m9t; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C6708378002; Wed, 28 Oct 2026 07:08:08 -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 98894378002 for ; Wed, 28 Oct 2026 07:08:06 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0BAC84BA79B6 for ; Wed, 28 Oct 2026 11:08:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0BAC84BA79B6 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=HSfy4m9t Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 534AA4BA798A for ; Wed, 28 Oct 2026 11:07:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 534AA4BA798A 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 534AA4BA798A 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=1793185656; cv=none; b=lU0NfpfLKUncGD8rCpBtHoURIHRo6Sv3UnnfmW94JIisO8lxSWvruEaOCxm3F0yqbv98vy0QovSoh15CwyU399Z/K+DEnW1bb7h65ghnbr2Mb12z8SJgVPBuGvdQN2dtGu23z4Ap981ttf6m3Yton4fh3n6c6hkRMXD4wCSzvnw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1793185656; c=relaxed/simple; bh=lpnRPOIoLWjfbBy+NZAaUFpwwTzREVl140BfowqZ3/s=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=jx3D15VrLSkPCp5k04RDV3krZIbViQeqwvs632cj9mKdqUbBaHgDlarAfh8olktZ8kOaucc0FhERleHDX/FIhDRB933ueQwZHzeCAkXMMGV0kgLGA8QvUh8HgmPXw6Vt19GtrPVphaFGPMwoF7fl3MN20Xi7tn7RihZa9iMtgEw= 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=HSfy4m9t DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 534AA4BA798A 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 69S8i6xI978988; Wed, 28 Oct 2026 11:07:25 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=lH262NDk0sOHI2jrvAhyQkfh1/BYBJ IPX5sf03xByFM=; b=HSfy4m9t8zNGtFXQ5B5r0h/A3c7+xEvfKSrEfxKcUSHoM4 MlwCQBUb/HmGN3eYsi4zYG+wkkZdL6XSEVOTMfqUkXNT5x9qZeYYU6+e7zx05bQV q0Md+2qOqWz8Y/zRAMfkgOxwRMwdkdhB+0saxMTHjM7iH+XXwij/VydThiploB4H pLayY9EHpi54AL0rhKosX3uaKTbN5MVgv8YJUjy6n5/PGMslbUg/4CFAsfeiMQnL ksIz7QCQNLGXfF0pTW7SCR/4N/2B1o/W87LamMyZJH4G65XzwC2QGccPVjOA0Rp7 x9mibkZtqfW7SQRq/ybN2wZ2naOLtlAAaHR3Ivnw== Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4hgm644at3-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 28 Oct 2026 11:07:25 +0000 (GMT) Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.18.1.11/8.18.1.11) with ESMTP id 69S8KAc9089932; Wed, 28 Oct 2026 11:07:24 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 4hk010k79b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 28 Oct 2026 11:07:24 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (smtpav06.wdc07v.mail.ibm.com [10.39.53.233]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 69SB7JX428443134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 28 Oct 2026 11:07:19 GMT Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 33F2B58066; Wed, 28 Oct 2026 10:42:14 +0000 (GMT) Received: from smtpav06.wdc07v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 03DAE58062; Wed, 28 Oct 2026 10:42:12 +0000 (GMT) Received: from [9.127.11.2] (unknown [9.127.11.2]) by smtpav06.wdc07v.mail.ibm.com (Postfix) with ESMTP; Wed, 28 Oct 2026 10:42:11 +0000 (GMT) Content-Type: multipart/alternative; boundary="------------ZLLDG2YvJupGv7Yb2OBHnJkW" Message-ID: Date: Wed, 28 Oct 2026 16:12:10 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 2/2] gdb: add stat64 and fstat64 to the F-packet file-i/o protocol To: Ulrich Weigand , "gdb-patches@sourceware.org" Cc: Andrew Burgess , "eliz@gnu.org" , "cel@linux.ibm.com" , Abhay Kandpal References: <20261014092139.399322-1-abhay@linux.ibm.com> <20261014092139.399322-3-abhay@linux.ibm.com> <21b9f02739bfd9fc0f57368050b5fa98de9c5e05.camel@de.ibm.com> From: Abhay Kandpal Content-Language: en-GB In-Reply-To: <21b9f02739bfd9fc0f57368050b5fa98de9c5e05.camel@de.ibm.com> X-TM-AS-GCONF: 00 X-Proofpoint-Spam-Info: AW1haW4tMjYxMDI4MDA0MiBTYWx0ZWRfX1cPZw4S2zZcK MaDWtpCUU4R9gMfYjY7r8pIHB1NYzOpaJ3ssFGghxxXbiwPB+cSbvFKHaqaqDA0gwccJRVGhjI1 JVn5H0YHuLfzL8fj3/+swA5ygqniBAU= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYxMDI4MDA0MiBTYWx0ZWRfX7IS6DqsDVCZV XpQX05DIugrRTP/uQAgtwjuqqPLmtUVCQf8vVgqBfSAIoQpWJjcRF2Vs+HT2ophSf/tyjYoTnot Kx6WQbFjUn4WCM0fgOgyNQPH9sN1cISHuNOupjmxd4z1BJFlX7uj/0P10xiYJipUdb7rS5vFpIe RhU4IPV+i+kyrRjLruJdAu2L5HdxSnMJWeHn9tOZ34MB6ua+byLiooFUr6g1+S0+Z7Ltmu2zYZi x2vCZsailRYdUzZQYoSDVDVRdih0+pXeEtWY9sh400X39eWwRggpaLVPBHyCY78stRZgawOsCNI Bnj9V4ipLgvrhBuaEoAF1B6TY1M+l+lIdZQG27yU6usiHGS53xlFdn/qImG1cm0C12ctsNFQkGg 6iFD4pv5oMcKpH7szejlRbmITBR51f4UcJ1hrtBbYZLm+7z/z8ioobUEUrklr0TbjFDZu6isLlx +u2u8BPPPNmyuj+ZlzA== X-Proofpoint-ORIG-GUID: oqdnsVSe2-AR3qB6a7J6kyt0l-vs3DRF X-Authority-Analysis: v=2.4 cv=Uu32pOwB c=1 sm=1 tr=0 ts=6ae1d76d cx=c_pps a=AfN7/Ok6k8XGzOShvHwTGQ==:117 a=AfN7/Ok6k8XGzOShvHwTGQ==:17 a=660iZSQnnn4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=r77TgQKjGQsHNAKrUKIA:9 a=CCpqsmhAAAAA:8 a=VnNF1IyMAAAA:8 a=O0DY5FRAZtaxvgH8Y04A:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=eZ8WpNYoW9urU0ZkXYAA:9 a=US4rxcgWYBNIfMof:21 a=_W_S_7VecoQA:10 a=lqcHg5cX4UMA:10 a=ul9cdbp4aOFLsgKbc677:22 X-Proofpoint-GUID: oqdnsVSe2-AR3qB6a7J6kyt0l-vs3DRF X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.138,FMLib:17.12.100.49 definitions=2026-10-28_03,2026-10-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 impostorscore=0 priorityscore=1501 spamscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 clxscore=1015 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2610190000 definitions=main-2610280042 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. --------------ZLLDG2YvJupGv7Yb2OBHnJkW Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Ulrich, Thanks for looking. On 27/10/26 23:17, Ulrich Weigand wrote: > Abhay Kandpal wrote: > >> The F-packet calls cannot use qSupported, since the buffer is read >> directly by the target.  But each request names the call it wants, so >> add two new calls, Fstat64 and Ffstat64, which are identical to Fstat >> and Ffstat except that they write struct fio_stat_wide.  Existing >> targets keep using Fstat and Ffstat and see no change.  A GDB which >> does not know the new calls already replies with ENOSYS, so a target >> can try Fstat64 and fall back to Fstat. > This makes sense to me, if support for this is needed. I'm not > really sure who -if anyone- is using these F-packets; gdbserver > doesn't seem to do so and there's no test in the test suite ... > > Andrew, do you have any thoughts on this? One user is QEMU: its semihosting code (semihosting/syscalls.c) sends F-packet requests for every call in the protocol, including both stat and fstat. I added 2/2 because Andrew preferred both directions to be fixed, and I'm happy to go either way. > > >> The console case in the fstat handler stored 1 into fst_dev, but that >> was then overwritten when the struct was packed, so the target always >> saw zero.  Drop the dead store; behaviour is unchanged. > Interesting. Seems this accidentally changed here: > https://sourceware.org/pipermail/gdb-patches/2015-March/122143.html > > which says: > (remote_fileio_mode_to_target): Moved to common-remote- > fileio.c. > (remote_fileio_to_fio_mode): Likewise. > (remote_fileio_to_fio_ulong): Likewise. > (remote_fileio_to_fio_stat): Likewise. > > but in addition to the move, changed: > > -static void > -remote_fileio_to_fio_stat (struct stat *st, struct fio_stat *fst) > -{ > - LONGEST blksize; > - > - /* `st_dev' is set in the calling function. */ > - remote_fileio_to_fio_uint ((long) st->st_ino, fst->fst_ino); > > to: > > +void > +remote_fileio_to_fio_stat (struct stat *st, struct fio_stat *fst) > +{ > + LONGEST blksize; > + > + remote_fileio_to_fio_uint ((long) st->st_dev, fst->fst_dev); > + remote_fileio_to_fio_uint ((long) st->st_ino, fst->fst_ino); > > > So up until 2015 fst_dev was indeed 1 for the console and > 0 for everything else, and since then it's been 0 always. > Given that long time, it may be fine to keep it at 0 now ... > > On the other hand, the documentation still says: > > @item st_dev > A value of 0 represents a file, 1 the console. > > So we can either fix the code again, or else update the > documentation to match the behavior over the last 10 years. > Thoughts? There is a second mismatch as well. For a regular file, the fstat handler never sets fst_dev, so the host's real st_dev is passed through rather than the documented 0. Today only stat matches the documentation: stat, file: documented 0, sends 0 fstat, console: documented 1, sends 0 fstat, file: documented 0, sends the host's st_dev My preference would be to fix the code to match the documentation, since the 2015 change looks accidental. I'd do that as a separate patch, so it doesn't depend on the stat64 series. Thanks Abhay > > Bye, > Ulrich --------------ZLLDG2YvJupGv7Yb2OBHnJkW Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 
Hi Ulrich, 
Thanks for looking.
On 27/10/26 23:17, Ulrich Weigand wrote:
Abhay Kandpal <abhay@linux.ibm.com> wrote:


The F-packet calls cannot use qSupported, since the buffer is read
directly by the target.  But each request names the call it wants, so
add two new calls, Fstat64 and Ffstat64, which are identical to Fstat
and Ffstat except that they write struct fio_stat_wide.  Existing
targets keep using Fstat and Ffstat and see no change.  A GDB which
does not know the new calls already replies with ENOSYS, so a target
can try Fstat64 and fall back to Fstat.

This makes sense to me, if support for this is needed.  I'm not
really sure who -if anyone- is using these F-packets; gdbserver
doesn't seem to do so and there's no test in the test suite ...

Andrew, do you have any thoughts on this?
One user is QEMU: its semihosting code (semihosting/syscalls.c)
sends F-packet requests for every call in the protocol, including
both stat and fstat. I added 2/2 because Andrew preferred both
directions to be fixed, and I'm happy to go either way.



The console case in the fstat handler stored 1 into fst_dev, but that
was then overwritten when the struct was packed, so the target always
saw zero.  Drop the dead store; behaviour is unchanged.

Interesting.  Seems this accidentally changed here:
https://sourceware.org/pipermail/gdb-patches/2015-March/122143.html

which says:
	(remote_fileio_mode_to_target): Moved to common-remote-
fileio.c.
	(remote_fileio_to_fio_mode): Likewise.
	(remote_fileio_to_fio_ulong): Likewise.
	(remote_fileio_to_fio_stat): Likewise.

but in addition to the move, changed:

-static void
-remote_fileio_to_fio_stat (struct stat *st, struct fio_stat *fst)
-{
-  LONGEST blksize;
-
-  /* `st_dev' is set in the calling function.  */
-  remote_fileio_to_fio_uint ((long) st->st_ino, fst->fst_ino);

to:

+void
+remote_fileio_to_fio_stat (struct stat *st, struct fio_stat *fst)
+{
+  LONGEST blksize;
+
+  remote_fileio_to_fio_uint ((long) st->st_dev, fst->fst_dev);
+  remote_fileio_to_fio_uint ((long) st->st_ino, fst->fst_ino);


So up until 2015 fst_dev was indeed 1 for the console and
0 for everything else, and since then it's been 0 always.
Given that long time, it may be fine to keep it at 0 now ...

On the other hand, the documentation still says:

@item st_dev
A value of 0 represents a file, 1 the console.

So we can either fix the code again, or else update the
documentation to match the behavior over the last 10 years.
Thoughts?
There is a second mismatch as well. For a regular file, the fstat
handler never sets fst_dev, so the host's real st_dev is passed
through rather than the documented 0. Today only stat matches
the documentation:

stat, file:        documented 0, sends 0
fstat, console:    documented 1, sends 0
fstat, file:       documented 0, sends the host's st_dev

My preference would be to fix the code to match the documentation,
since the 2015 change looks accidental. I'd do that as a separate
patch, so it doesn't depend on the stat64 series.

Thanks
Abhay

Bye,
Ulrich
--------------ZLLDG2YvJupGv7Yb2OBHnJkW--