From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88658 invoked by alias); 26 Feb 2019 16:04:20 -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 88647 invoked by uid 89); 26 Feb 2019 16:04:20 -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= 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; Tue, 26 Feb 2019 16:04:13 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyfDI-00011s-0S; Tue, 26 Feb 2019 11:04:12 -0500 Received: from [176.228.60.248] (port=2565 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyfDH-0005bL-I8; Tue, 26 Feb 2019 11:04:11 -0500 Date: Tue, 26 Feb 2019 16:04:00 -0000 Message-Id: <83y362lenr.fsf@gnu.org> From: Eli Zaretskii To: Tom Tromey CC: gdb-patches@sourceware.org In-reply-to: <87o96ztwpa.fsf@tromey.com> (message from Tom Tromey on Mon, 25 Feb 2019 13:55:13 -0700) Subject: Re: [RFC 00/17] Merge event loop implementations References: <20190224165153.5062-1-tom@tromey.com> <83sgwdnm6r.fsf@gnu.org> <87va19jdy4.fsf@tromey.com> <83r2bxnkrb.fsf@gnu.org> <87imx7vdxe.fsf@tromey.com> <83lg23mx18.fsf@gnu.org> <87o96ztwpa.fsf@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/msg00435.txt.bz2 > From: Tom Tromey > Cc: Tom Tromey , gdb-patches@sourceware.org > Date: Mon, 25 Feb 2019 13:55:13 -0700 > > Eli> Can you point me to the gdbserver code which calls 'socket' and > Eli> 'accept' on Windows, whose results are used in 'select'? I'd like to > Eli> see what it does on Windows, to be able to have a better idea of what > Eli> adaptations would be necessary for Gnulib's 'select'. > > Everything is in gdb/gdbserver/remote-utils.c. Search for the calls to > add_file_handler. > > handle_accept_event calls accept, sets remote_desc, then calls > add_file_handler for it. Thanks. It sounds like most of the adaptation is to use Gnulib's replacements for these functions, and remove most or all of the USE_WIN32API ifdef's. > remote_open does the other call. It is maybe less than obvious but this > code rules out the use of stdin on windows: > > #ifdef USE_WIN32API > if (port_str == NULL) > error ("Only HOST:PORT is supported on this platform."); > #endif > > So, the STDIO_CONNECTION_NAME branch cannot be taken; the others are > #if'd out; leaving just the final one that calls add_file_handler on > listen_desc. listen_desc is actually created in remote_prepare. I guess stdin is disabled because 'select' doesn't support it. But with Gnulib, we could allow that, although perhaps not in the initial phase of the changes. > Eli> Offhand, I think we'd need just the trivial adaptations, like make > Eli> sure gdbserver uses file descriptors instead of HSOCKETs on Windows as > Eli> well. Probably it would be best to import Gnulib's 'socket' and > Eli> 'accept' as well, and use their SOCKET_TO_FD and FD_TO_SOCKET macros > Eli> if/where needed (hopefully nowhere). Are there any more related APIs, > Eli> besides those 3? I guess, 'close' (which should call 'closesocket' on > Eli> Windows) and perhaps 'ioctl'? Gnulib has those as well. > > gdbserver uses setsockopt as well. And also 'accept' and 'bind', all of them are available in Gnulib. As a nice bonus, we get to remove the USE_WIN32API parts that call 'closesocket' where on Posix platforms we call 'close', because Gnulib's 'close' does that as well. So, on balance I think if we want to remove USE_WIN32API regarding sockets and related stuff, importing Gnulib replacements will be much less work, and might also enable some features that are currently disabled.