From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106212 invoked by alias); 24 Feb 2019 17:14:19 -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 106191 invoked by uid 89); 24 Feb 2019 17:14:19 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:142, feed X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Feb 2019 17:14:17 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43964) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxxLz-0004Vr-Ot; Sun, 24 Feb 2019 12:14:15 -0500 Received: from [176.228.60.248] (port=4208 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gxxLz-00027V-8V; Sun, 24 Feb 2019 12:14:15 -0500 Date: Sun, 24 Feb 2019 17:14:00 -0000 Message-Id: <83sgwdnm6r.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <20190224165153.5062-1-tom@tromey.com> (message from Tom Tromey on Sun, 24 Feb 2019 09:51:36 -0700) Subject: Re: [RFC 00/17] Merge event loop implementations References: <20190224165153.5062-1-tom@tromey.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00409.txt.bz2 > From: Tom Tromey > Date: Sun, 24 Feb 2019 09:51:36 -0700 > > The second unresolved issue involves the USE_WIN32API code. Before > this series, gdbserver used gdb_fildes_t, defined like: > > #if USE_WIN32API > #include > typedef SOCKET gdb_fildes_t; > #else > typedef int gdb_fildes_t; > #endif > > gdb did not use this approach, but does have a separate gdb_select > implementation in mingw-hdep.c, which gdbserver does not. > > I don't know much about Windows, so I don't know why these things are > needed. I did a build using " --host=i686-w64-mingw32 > --target=i686-w64-mingw32", and everything built just fine using a > POSIX-style API. > > Given that, I removed gdb_fildes_t in this series. However, perhaps > it is still needed and this series needs some more work. I could use > some advice here -- when is this code actually needed and is there a > way I can reproduce any problems? I don't have a Windows host, so I'm > hoping for some sort of compile-time error using a mingw cross. The problem here is that Windows' implementation of 'select' works only on sockets, and wants HSOCKET handles instead of file descriptors. If you feed it a file descriptor, it won't work, even if the descriptor is for a socket. I cannot really tell, by reading the patches, what code would gdbserver on Windows use after this series, so I don't know whether it will be broken or not. But one thing I do see is that mingw-hdep.c doesn't support waiting on write descriptors, whereas gdbserver's event-loop.c seems to support that.