From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4s3OLRcj4WolnzIAWB0awg (envelope-from ) for ; Tue, 27 Oct 2026 18:17:59 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Jde3t+xU; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 39982378002; Tue, 27 Oct 2026 18:17:59 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 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 17F431E007 for ; Tue, 27 Oct 2026 18:17:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 165BD4BA23D5 for ; Tue, 27 Oct 2026 22:17:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 165BD4BA23D5 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Jde3t+xU Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id BED144BA2E26 for ; Tue, 27 Oct 2026 22:17:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BED144BA2E26 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org BED144BA2E26 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1793139429; cv=none; b=VSz+b8vZENo5H94L8LQ3BSLyfIvtOEQte+KIhcSr37ABme6Fkc0PuuKPiSoxkLYmWq/MVbK3b1qmTBq5hssvAyuk/kdRIBOpByXkDr5BHIzEI+tghEBMLjOkbkLc5+fvXsQj7RkRMZhthcEPkQmAT/Ei5+z0cFd3MwFG8r9oSAI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1793139429; c=relaxed/simple; bh=kA3FBS9ws/ZFtLRKGLqVc5s0u1ytmOgGyVpHw+D6Wk0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=mHeyTPfiCp7nTkyESgUlwCFSxoQpwNY5OTqYe29WnLOWasrtIdt3mBhA4sU9sb9ObupQ41LZAJjce7+fODiTGA+xMiwcEMUrPi9fPJXXuZFTe1FqjustshUKUFhYo3W9LZ0aos7kqT2pOJnHyELDAcVyhz5oWaQoijzBVwxy6uQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=Jde3t+xU DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BED144BA2E26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1793139429; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=61TEcWlYkF+KNQFqvGHzFCd03kxJK9w7UolQRP3KBgQ=; b=Jde3t+xUSATTj2AvfdAO/5YSpm43ZAvw9GU58rSKpseOvGYkNcV2zW2eNbZQLTgFOU43ny TSEnflHyfPZ0NAEUzF/ZFLD/1pOo68x+Jgw9KcsXiJ4NauS9Rm2XH0dVA+urU+y3jOqV7K Llq74mZvhGROfUUinQlGihwj7yR1ey0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-82-08ngTSi3POaWZsNHwIMq4A-1; Tue, 27 Oct 2026 18:17:01 -0400 X-MC-Unique: 08ngTSi3POaWZsNHwIMq4A-1 X-Mimecast-MFC-AGG-ID: 08ngTSi3POaWZsNHwIMq4A_1793139421 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-48b02d63407so224163f8f.0 for ; Tue, 27 Oct 2026 15:17:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1793139420; x=1793744220; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=61TEcWlYkF+KNQFqvGHzFCd03kxJK9w7UolQRP3KBgQ=; b=HTxNolXMVQ3PpzhjaH850nVFqtnT9qRjUrNjm23SHfk4u54sPe9tPuy6sHWPipUT4y hX4E1r864KtDYU/YSbVKB5x62JfK3mtfxpY064K897idTMSBQww5F9OSGHDf7eMBQW7T voT7dSEIBzEbtS1ywPYL7bKPRsSbOtZpDAjRsb8WidduzUDsNHqHqR/oLNNdlHf9LqXe PRD9TFdrHXgtvdm1DoZccR8yDzfPx94e1B5vL4A/qTjgiMjCz8OfNkxUYKEn62/Ao8HF +jj+7IzL9sgIhyoV4XkDcm2naBmvcS0JmUJkbJcsb7dA95RRPjGFcnFS145Fi3ltrcWd Gx3w== X-Forwarded-Encrypted: i=1; AKwUvBx7tgiMN49bC3OaWU5/YaqopnM9SDziwlJGGr7bxq4SkfaaU4IPrKbipR/MwzPiQq95gdVa5GrtQOBJ0Q==@sourceware.org X-Gm-Message-State: AFq9FYL5h9Zh4t+BXRMQChEyEhYjw7BxEP7yJdUG/UObDDj+s+j7pwjR G1aCXjidWPCjiwuha2yx7Rws80/SoFYYb6AyiM3av9W3cBvJQUyRF92M64OefcPnBN92f7y9PJT 1YDpPtZYdyiOM7YDXoqHinpcVtltixusgEV2kqv+CykCKfEdc3bIPnpsJkD6iJ3k= X-Gm-Gg: AYBFou0f6ORKzx6l/rusxj8uhjoQ/AyvltmyOQ1H9XvKUL1UusxAivRPK1vjHo6SWvp nf3ywGgFAUwPsIqTgrrxJeiLK6MG5gJck0iPPA4+S9/bpgp/pm5z/wixdvff4m/38LDPDnmJh8z Y53QeBLdI0lBxSymj5tkBan8+bJ8M2qpsc93OVxz+Bfe3KSEJjAUPk7foeDtyBuVeDuTduDLgwT xC5TM7J/7ROHzTb843TKjMEbxz+5KVugwIzvv2ok63gN5zyHAoAM2492QLEeBYAzN84V8+NsBob 5GlkC8XAwFIVMF+G+PsA48WSiHclr2Dwfor/5SJqOPl+Qfr04mO0ZQ9jHEu2dnfomEUT+xMu/g= = X-Received: by 2002:a05:6000:2806:b0:48d:ff0d:cfa5 with SMTP id ffacd0b85a97d-48e5d5e237bmr1096552f8f.47.1793139420428; Tue, 27 Oct 2026 15:17:00 -0700 (PDT) X-Received: by 2002:a05:6000:2806:b0:48d:ff0d:cfa5 with SMTP id ffacd0b85a97d-48e5d5e237bmr1096525f8f.47.1793139419875; Tue, 27 Oct 2026 15:16:59 -0700 (PDT) Received: from localhost ([2a00:23c6:e11d:fb01:6748:4fce:3e30:6e23]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-48e3ebc3c5bsm25850976f8f.9.2026.10.27.15.16.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Oct 2026 15:16:59 -0700 (PDT) From: Andrew Burgess To: Abhay Kandpal , gdb-patches@sourceware.org Cc: Ulrich.Weigand@de.ibm.com, eliz@gnu.org, cel@linux.ibm.com, abhay.k@ibm.com, Abhay Kandpal Subject: Re: [PATCH v3 1/2] gdbserver: widen the stat fields returned by the vFile packets In-Reply-To: <20261014092139.399322-2-abhay@linux.ibm.com> References: <20261014092139.399322-1-abhay@linux.ibm.com> <20261014092139.399322-2-abhay@linux.ibm.com> Date: Tue, 27 Oct 2026 22:16:58 +0000 Message-ID: <87wlr27pr9.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: nUQ2ldeCqxRrI5TGaiN5pwZetVFjswGBMDHbavncyAE_1793139421 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Abhay Kandpal writes: > The struct sent by the vFile:fstat, vFile:stat and vFile:lstat packets > declares st_dev, st_ino, st_nlink, st_rdev and the three timestamps as > 4-byte fields, while the corresponding struct stat members are 8 bytes > on a 64-bit host. The values are silently truncated. > > This is not visible on a filesystem whose inode numbers stay below > 2^32, but it is on a large one. On an 86 TB xfs volume, > gdb.server/fileio-packets.exp fails because the inode reported by > vFile:lstat does not match the one reported locally: > > remote = {..., 'st_ino': 2161233200, ...} > local = {..., 'st_ino': 122420317488, ...} > > The field widths cannot simply be changed, as that would alter the wire > layout and break communication between different versions of GDB and > gdbserver. Add a new 'stat64' qSupported feature instead. When both > sides report it, the vFile stat packets return struct fio_stat_wide, in > which the six too-narrow fields are 8 bytes; otherwise the existing Isn't is seven fields? st_dev, st_ino, st_nlink, st_rdev and the three timestamps. > struct fio_stat is used, exactly as before. > > Internally both GDB and gdbserver now work with the wide struct, and > the conversion happens at the wire boundary: gdbserver narrows the > result before sending it if the feature was not negotiated, and GDB > selects the unpacker by the length of the reply. Narrowing a value > which does not fit now produces a warning rather than truncating > silently. > > The F-packet file-i/o protocol uses the same struct, but writes it > into inferior memory rather than sending it as packet data, so it > cannot use qSupported negotiation. It is handled separately in the > next patch. > > While here, drop a duplicate include of gdbsupport/fileio.h from > gdbserver/hostio.cc. > > Tested on powerpc64le-linux; gdb.server/fileio-packets.exp now passes on > a filesystem with inode numbers above 2^32 and continues to pass on one > without, with no unexpected failures in the full testsuite. > > 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. These style of changelog entries are no longer used in GDB and shouldn't be included. > @@ -13656,29 +13667,35 @@ remote_target::fileio_readlink (struct inferior *inf, const char *filename, > remote syscall reply. EXPECTED_LEN is the length returned from the > fstat or stat call, this the length of the returned data (in ATTACHMENT) > once it has been decoded. The fstat/stat result (from the ATTACHMENT > - data) is to be placed in ST. */ > + data) is to be placed in ST. > > + The reply holds either a struct fio_stat or, if the stat64 feature was > + negotiated, the wider struct fio_stat_wide; the two are distinguished > + by their length. */ > static int I think you lost the blank line between the comment and the 'static int' line. > fileio_process_fstat_and_lstat_reply (const char *attachment, > int attachment_len, > int expected_len, > struct stat *st) > { > - struct fio_stat fst; > + gdb_byte buf[sizeof (struct fio_stat_wide)]; > > int read_len > = remote_unescape_input ((gdb_byte *) attachment, attachment_len, > - (gdb_byte *) &fst, sizeof (fst)); > + buf, sizeof (buf)); > > @@ -519,16 +533,31 @@ handle_stat (char *own_buf, int *new_packet_len) > return; > } > > - host_to_fileio_stat (&st, &fst); > - > - bytes_sent = hostio_reply_with_data (own_buf, > - (char *) &fst, sizeof (fst), > - new_packet_len); > + struct fio_stat_wide wide; > + host_to_fileio_stat_wide (&st, &wide); > > - /* If the response does not fit into a single packet, do not attempt > - to return a partial response, but simply fail. */ > - if (bytes_sent < sizeof (fst)) > - write_enn (own_buf); > + /* Send the wide form if GDB understands it, otherwise narrow the > + result first. */ > + if (cs.stat64_feature) > + { > + bytes_sent = hostio_reply_with_data (own_buf, (char *) &wide, > + sizeof (wide), new_packet_len); > + /* If the response does not fit into a single packet, do not attempt > + to return a partial response, but simply fail. */ > + if (bytes_sent < sizeof (wide)) > + write_enn (own_buf); > + } > + else > + { > + struct fio_stat narrow; > + fileio_stat_wide_to_narrow (&wide, &narrow); > + bytes_sent = hostio_reply_with_data (own_buf, (char *) &narrow, > + sizeof (narrow), new_packet_len); > + /* If the response does not fit into a single packet, do not attempt > + to return a partial response, but simply fail. */ > + if (bytes_sent < sizeof (narrow)) > + write_enn (own_buf); > + } This pattern is repeated 3 times. I wonder if you could factor out a helper function, hostio_send_stat_reply, to handle this duplication? > } > > static void > diff --git a/gdbserver/server.h b/gdbserver/server.h > index bbba3650de7..cf811f228fa 100644 > --- a/gdbserver/server.h > +++ b/gdbserver/server.h > @@ -192,6 +192,11 @@ struct client_state > /* If true, memory tagging features are supported. */ > bool memory_tagging_feature = false; > > + /* True if GDB supports the wide form of struct stat in the vFile > + fstat, stat and lstat replies. When false, gdbserver narrows the > + result to struct fio_stat before sending it. */ > + bool stat64_feature = false; If you search in gdbserver/server.cc for the comment text 'Be sure we're out of tfind mode', you'll find a block of code that resets all of these feature flags. There is already a bug (introduced by me) for a feature flag that is not being reset in this block correctly. But your flag also needs resetting here too. Without this, then when we reconnect the feature flag from the previous connection will remain turned on. > + > /* If true then E.errtext style errors are supported everywhere, > including for the qRcmd and m packet. When false E.errtext errors > are not supported with qRcmd and m packets, but are still supported > @@ -199,4 +238,13 @@ host_to_fileio_time (time_t num, fio_time_t fnum) > > extern void host_to_fileio_stat (struct stat *st, struct fio_stat *fst); > > +/* Pack a host-format struct stat into a struct fio_stat_wide. */ > +extern void host_to_fileio_stat_wide (struct stat *st, > + struct fio_stat_wide *fst); > + > +/* Narrow a struct fio_stat_wide into a struct fio_stat, warning if any > + value does not fit. */ > +extern void fileio_stat_wide_to_narrow (const struct fio_stat_wide *wide, > + struct fio_stat *narrow); GDB style leaves a blank line after the comment and before a function declaration or definition. Mostly. We're not perfect. But that's what it's supposed to be. This file looks to be following the style, so it would be nice if this new code did too please. There's also a place in gdbserver/hostio.h which should be fixed too please. Thanks, Andrew > + > #endif /* GDBSUPPORT_FILEIO_H */ > -- > 2.52.0