Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Julio Guerra <julio@farjump.io>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: Corinna Vinschen <vinschen@redhat.com>
Subject: Re: [PATCH] Do not clear the value of st_dev in File I/O's stat()
Date: Thu, 17 May 2018 15:31:00 -0000	[thread overview]
Message-ID: <9445cc6c-a954-7cdf-d0dc-47a18e596db3@redhat.com> (raw)
In-Reply-To: <010201636d368a34-7edcde92-3661-4c9a-94b4-a894b9c8e90a-000000@eu-west-1.amazonses.com>

[Hi Corinna, adding you in case you still happen to remember
any of this and have any input.  If not, that's fine.]

On 05/17/2018 09:28 AM, Julio Guerra wrote:
> Do not clear the value of st_dev in the fileio stat structure sent to the
> target. It prevents from being able to check the file type on the target.
> Note that the fileio function fstat `remote_fileio_func_fstat()` doesn't clear
> this field.

Curious.  This looked like was written in a way like you'd write if you
had a reason to so I did some archaeology to try to find what it was, see
if the reason is still valid.

I found the original File I/O protocol proposal here:

  https://www.sourceware.org/ml/gdb/2002-11/msg00107.html

and in there, in the intro, it said:

~~~~~
  The protocol is only used for files on the host file system and
  for I/O on the console.  Character or block special devices, pipes,
  named pipes or sockets or any other communication method on the host
  system are not supported by this protocol.
~~~~~

and further below, in "B.3 struct stat", it says:

~~~~~
  The values of several fields have a restricted meaning and/or
  range of values.

    st_dev:	0	file
		1	console
~~~~~

And the current manual also says:

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

And it looks like early on, in:

 https://sourceware.org/ml/gdb-patches/2003-03/msg00221.html

we had:

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

Note the comment.  

I can't find the comment in the current sources, but it was there
up until:

 commit 791c00567a7ccbae3d71e3b63ac43c0b555079dc
 Author:     Gary Benson <gbenson@redhat.com>
 AuthorDate: Wed Mar 11 17:53:57 2015 +0000

    Move remote_fileio_to_fio_stat to gdb/common


and note that remote_fileio_func_fstat still does:

  if (fd == FIO_FD_CONSOLE_IN || fd == FIO_FD_CONSOLE_OUT)
    {
      host_to_fileio_uint (1, fst.fst_dev);
                          ^^^

"fstat" was only added later on, along the work that Gary did
around that commit above, for this series:

 https://sourceware.org/ml/gdb-patches/2015-03/msg00286.html

... which introduced "fstat" in the protocol, and in that case,
the 0/1 st_dev issue was either missed or ignored, so
fstat is not following the documented values.

Now I'm not sure what to do.  If we let the real st_dev
through, what shall we fill it in, in the "console" files
case?

> 
> 2018-05-16  Julio Guerra  <julio@farjump.io>
> 
> 	* remote-fileio.c: do not clear the value of st_dev in File I/O's stat().

Nit, you'd write:

gdb/ChangeLog:
2018-05-16  Julio Guerra  <julio@farjump.io>

	* remote-fileio.c (remote_fileio_func_stat): Do not clear the
	value of st_dev.

Thanks,
Pedro Alves


  reply	other threads:[~2018-05-17 14:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20180517082631.26855-1-julio@farjump.io>
2018-05-17 10:32 ` Julio Guerra
2018-05-17 15:31   ` Pedro Alves [this message]
     [not found]     ` <496efebf-0f96-4586-de39-0a1857994f04@farjump.io>
2018-05-18 18:29       ` Julio Guerra
2018-05-28 10:50     ` Corinna Vinschen
     [not found]       ` <6f5980ae-247c-1991-ba3c-884fe04a94c5@farjump.io>
2018-05-28 12:49         ` Julio Guerra
2018-05-28 13:18           ` Pedro Alves

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=9445cc6c-a954-7cdf-d0dc-47a18e596db3@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=julio@farjump.io \
    --cc=vinschen@redhat.com \
    /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