From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29638 invoked by alias); 28 May 2018 10:41:58 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 29628 invoked by uid 89); 28 May 2018 10:41:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=corinna, Corinna, vacation, os X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 28 May 2018 10:41:56 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2C1C5BD9E; Mon, 28 May 2018 10:41:55 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-117-198.ams2.redhat.com [10.36.117.198]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 04BE8210C6CB; Mon, 28 May 2018 10:41:54 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id B1782A8096C; Mon, 28 May 2018 12:41:53 +0200 (CEST) Date: Mon, 28 May 2018 10:50:00 -0000 From: Corinna Vinschen To: Pedro Alves Cc: Julio Guerra , gdb-patches@sourceware.org Subject: Re: [PATCH] Do not clear the value of st_dev in File I/O's stat() Message-ID: <20180528104153.GA3501@calimero.vinschen.de> References: <20180517082631.26855-1-julio@farjump.io> <010201636d368a34-7edcde92-3661-4c9a-94b4-a894b9c8e90a-000000@eu-west-1.amazonses.com> <9445cc6c-a954-7cdf-d0dc-47a18e596db3@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9445cc6c-a954-7cdf-d0dc-47a18e596db3@redhat.com> User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-05/txt/msg00729.txt.bz2 Hi Pedro, On May 17 15:36, Pedro Alves wrote: > [Hi Corinna, adding you in case you still happen to remember > any of this and have any input. If not, that's fine.] Sorry for the late reply, just back from vacation. I remember this stuff patially only, but in terms of st_dev, I recall some discussion. > 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. > [...] The idea was that st_dev values on one system don't make sense on another system. Also, st_dev values for files reflect the underlying partition on the inferior system, which doesn't mean anything to the GDB host system. I don't know how important backward compat is here, but there may be code out there which still relies on the simple file vs. console st_dev from stat(). Version check? Other than that, if you think that this is an outdated approach, just make sure to change the docs as well. HTH, Corinna