From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52698 invoked by alias); 29 Jun 2018 15:01:15 -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 52616 invoked by uid 89); 29 Jun 2018 15:01:07 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= 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; Fri, 29 Jun 2018 15:01:00 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A1B0B818BAF8; Fri, 29 Jun 2018 15:00:58 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0DF561C739; Fri, 29 Jun 2018 15:00:57 +0000 (UTC) Subject: Re: [PATCH v3] Allow using special files with File I/O functions To: Julio Guerra , "gdb-patches@sourceware.org" References: <20180628192635.44056-1-julio@farjump.io> <0102016447dcf9e9-3989bcd9-1272-4a05-93c5-77823c7a0921-000000@eu-west-1.amazonses.com> <3c1caf7f-f50f-a8d7-43f3-f8fa8eca663d@redhat.com> <79758ca1-2541-9ae6-d793-b367d6094468@farjump.io> <010201644bd94c4b-0d8759a9-5625-4773-a858-6e218d4fc9db-000000@eu-west-1.amazonses.com> <9e53034b-7e28-625e-ad70-fbb53863c7e1@redhat.com> <6ea235bf-bc87-256a-e745-e54f5e97bf5c@farjump.io> <010201644bfcc9f7-34e2955f-fdda-460d-9ffd-f03a76b20d30-000000@eu-west-1.amazonses.com> From: Pedro Alves Message-ID: Date: Fri, 29 Jun 2018 15:01:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <010201644bfcc9f7-34e2955f-fdda-460d-9ffd-f03a76b20d30-000000@eu-west-1.amazonses.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-06/txt/msg00721.txt.bz2 On 06/29/2018 03:40 PM, Julio Guerra wrote: > Le 29/06/2018 à 16:28, Pedro Alves a écrit : >> On 06/29/2018 03:01 PM, Julio Guerra wrote: >> >>> I assumed a system >= POSIX.1-2001 here. man 7 inode says: >>> >>> >>> >>> The S_IF* constants are present in POSIX.1-2001 and later. >>> […] >>> The S_ISLNK() and S_ISSOCK() macros were not in POSIX.1-1996, but >>> both are present in POSIX.1-2001 >>> >>> >> POSIX specification != actual implementations. Also, Windows != POSIX, >> for example. See the gnulib page I pointed at. Also, looking through >> history with "git blame", etc. may find something. > > Isn't GDB compiled with mingw? I am no expert in mingw, but I thought it > was a POSIX implementation based on Windows. It's compiled with either MinGW or Cygwin. Cygwin is POSIX-like, but mingw is native Windows. > Anyway, we can add usual #ifdef guards arounds the cases. That may not be needed, but does not address the S_ISxxx vs S_IFxxx comment. Again, please take a look at the gnulib header. ISTM that S_ISxxx is always available (there's a default implementation that just returns 0), not sure about S_IFxxx. But please do take a better look. I've only skimmed it. >> >>> Yes, because of man 2 open: >>> >>> >>> >>> EISDIR: The named file is a directory and oflag includes O_WRONLY or O_RDWR, >>> or includes O_CREAT without O_DIRECTORY. >> I assume you're on Linux, so "man 2" is the Linux Programmer's manual. >> But GDB works in other hosts too. So it may be the code was there for >> some other host. I mean, why did someone write that in the first place? >> Again, sounds like some code archaeology is in order. > > Yes, but I checked it was POSIX too: > http://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html Again, spec vs implementation. It may not be needed, but I wouldn't be surprised if that was needed on e.g., Windows either. Again, archaeology may help here. >> >> I forgot to say in the previous email, but it would be really nice if we >> could add some coverage for these change to the testsuite. I've asked >> before but I don't remember the answer -- Would it be possible to portably >> update e.g. gdb.base/fileio.exp to cover at least one kind >> of FILEIO_STDEV_SPECIAL file? > > Ok, I'll have a look, but I thought there File IOs were not implemented > in gdbserver, so what runs this test? If it is natively run, it won't > cover remote_fileio_func_*. You can run the testsuite against other remote stubs, not just gdbserver. Ideally, you'd set up the testsuite to against your stub. Did you try that? I'd recommend that regardless. Otherwise, even if we only test it when natively run, other folks that have embedded stubs that support fileio will end up exercising the test. Thanks, Pedro Alves