From: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
To: Abhay Kandpal <abhay@linux.ibm.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Andrew Burgess <aburgess@redhat.com>,
"eliz@gnu.org" <eliz@gnu.org>,
"cel@linux.ibm.com" <cel@linux.ibm.com>,
Abhay Kandpal <Abhay.k@ibm.com>
Subject: Re: [PATCH v3 1/2] gdbserver: widen the stat fields returned by the vFile packets
Date: Tue, 27 Oct 2026 17:27:14 +0000 [thread overview]
Message-ID: <b935101e8f8cf0b3250dd0d1c32e24550fb616fd.camel@de.ibm.com> (raw)
In-Reply-To: <20261014092139.399322-2-abhay@linux.ibm.com>
Abhay Kandpal <abhay@linux.ibm.com> wrote:
>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
>struct fio_stat is used, exactly as before.
This looks all generally reasonable to me. A couple of minor comments.
>+static ULONGEST
>+remote_fileio_to_host_ulong8 (const char *fnum)
>+{
>+ return extract_unsigned_integer ((const gdb_byte *) fnum, 8,
>+ BFD_ENDIAN_BIG);
>+}
Why do we need this? The existing remote_fileio_to_host_ulong
should do the right thing already ...
>- 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);
Do we really need the wide_to_narrow conversion routine?
I think it would be preferable to convert from the host struct
directly to the fio_stat_wide in the if path and to fio_stat
in the else path. Otherwise we end up converting twice.
If we want to emit a warning, maybe that should be done
in host_to_fileio_uint ?
>+ 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 whole block is now duplicated three times, so it might be
worth a helper routine.
>+void
>+host_to_fileio_stat_wide (struct stat *st, struct fio_stat_wide *fst)
>+{
>+ LONGEST blksize;
>+
>+ host_to_bigendian ((LONGEST) st->st_dev, (char *) fst->fst_dev, 8);
>+ host_to_bigendian ((LONGEST) st->st_ino, (char *) fst->fst_ino, 8);
Again, we should be using the existing host_to_fileio_ulong.
Bye,
Ulrich
next prev parent reply other threads:[~2026-10-27 17:28 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-14 9:21 [PATCH v3 0/2] Widen the stat fields in the remote protocol Abhay Kandpal
2026-10-14 9:21 ` [PATCH v3 1/2] gdbserver: widen the stat fields returned by the vFile packets Abhay Kandpal
2026-10-27 17:27 ` Ulrich Weigand [this message]
2026-10-27 22:16 ` Andrew Burgess
2026-10-14 9:21 ` [PATCH v3 2/2] gdb: add stat64 and fstat64 to the F-packet file-i/o protocol Abhay Kandpal
2026-10-14 11:47 ` Eli Zaretskii
2026-10-27 17:47 ` Ulrich Weigand
2026-10-28 10:42 ` Abhay Kandpal
2026-10-28 14:19 ` Ulrich Weigand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b935101e8f8cf0b3250dd0d1c32e24550fb616fd.camel@de.ibm.com \
--to=ulrich.weigand@de.ibm.com \
--cc=Abhay.k@ibm.com \
--cc=abhay@linux.ibm.com \
--cc=aburgess@redhat.com \
--cc=cel@linux.ibm.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox