From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113475 invoked by alias); 24 Feb 2019 16:51:59 -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 113434 invoked by uid 89); 24 Feb 2019 16:51:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=socket, involves, sk:misunde, unifying X-HELO: gateway22.websitewelcome.com Received: from gateway22.websitewelcome.com (HELO gateway22.websitewelcome.com) (192.185.47.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 24 Feb 2019 16:51:56 +0000 Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 32D9D5F3A for ; Sun, 24 Feb 2019 10:51:55 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id xx0Ng40UiYTGMxx0NgLRLJ; Sun, 24 Feb 2019 10:51:55 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Message-Id:Date:Subject:To:From:Sender:Reply-To:Cc:MIME-Version :Content-Type:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=h9zYVt9EYh1jdAy3ivbh3W5kj4NCIfrBVz1QlEmBSJ0=; b=c5RHrw+P2JsgqTc1TIugPsv6sh u57fUxFj1dcqFLsYI6EMWIgGBeiLbBPvH0+vdBveCN4VCI2glLc6MKPtNTdo9+UbAsNDz08ZLSj6c iuAiIFTiorTfuymwOxrpp6fsv; Received: from 75-166-72-210.hlrn.qwest.net ([75.166.72.210]:44502 helo=bapiya.Home) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gxx0M-001AKk-V1 for gdb-patches@sourceware.org; Sun, 24 Feb 2019 10:51:55 -0600 From: Tom Tromey To: gdb-patches@sourceware.org Subject: [RFC 00/17] Merge event loop implementations Date: Sun, 24 Feb 2019 16:51:00 -0000 Message-Id: <20190224165153.5062-1-tom@tromey.com> X-SW-Source: 2019-02/txt/msg00391.txt.bz2 This series merges the gdb and gdbserver forks of event-loop.[ch]. This is an RFC because there are a few possibly unresolved issues. Most of the patches are straightforward. The series begins by tidying up the gdb event-loop code, removing things that are specific to gdb. Then, the code is moved. After this, gdbserver is switched to use the common code; and finally, a few cleanups are applied. I initially attempted something more ambitious here: unifying the async event and async signal code in event-loop (as I do not understand the reason for the difference); and then further handling the async signal code using the same code path as ordinary file descriptors. However, this didn't work, and since it was not directly important to my goal of merging event loops, I dropped it. I think it may be worth reviving. For example I think th async event code suffers from the same race that led Pedro to change the async signal code to use a the self-pipe trick. Another related possible to-do item is changing the ser-event code to maintain just a single self-pipe. It seems to me that there's never a reason to need more than one. create_file_handler may have a latent bug where the global select masks are not updated if it is called a second time for the same file descriptor. Both versions of the event loop have this issue; I didn't try to verify it, so perhaps I'm just misunderstanding the code here. The final patch simplifies the rather convoluted handling of "serial" (meaning remote protocol) input in gdbserver. It passes testing, but I wonder whether there's some subtle reason that the code is written the way it is. This is one of the unresolved issues I mentioned. 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. Regression tested by the buildbot. Tom