From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21672 invoked by alias); 27 Sep 2019 13:53:17 -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 21660 invoked by uid 89); 27 Sep 2019 13:53:17 -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.1 spammy=HX-Received:3281, wine X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Sep 2019 13:53:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1569592394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p4yjaBBjQLuBBGmPMY4PFVF6U6Z2WjVJgWVYzANP81U=; b=VBM7FLVO4gCM2AoaJZcyyiul0G05ALGokFAytaszcvc99EK7J6LFKbEhZGwxmbPX5IshCg UXclNM4QvFEHE43MxvOd+8GNRfP4AcTur3wgZ2YVtql4CfJ22rA2oSLBKl9v1vVEALYGTw AIi5NABPxA1JZ8m8MnzSgZw1/Y6R8N0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-246-bQ3ecgOFPzauWPJbWR0O8w-1; Fri, 27 Sep 2019 09:53:13 -0400 Received: by mail-wm1-f70.google.com with SMTP id z205so2795138wmb.7 for ; Fri, 27 Sep 2019 06:53:12 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id d9sm4385839wrf.62.2019.09.27.06.53.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Sep 2019 06:53:10 -0700 (PDT) Subject: Re: [RFC 00/17] Merge event loop implementations To: Tom Tromey References: <20190224165153.5062-1-tom@tromey.com> <3ae5ab8e-c219-6510-bb54-b30c1cf2d074@redhat.com> <87mueqslhn.fsf@tromey.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <52b71425-e839-99fa-5045-8aaa02eafaef@redhat.com> Date: Fri, 27 Sep 2019 13:53:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87mueqslhn.fsf@tromey.com> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-09/txt/msg00552.txt.bz2 On 9/27/19 12:09 AM, Tom Tromey wrote: >>>>>> "Pedro" =3D=3D Pedro Alves writes: >=20 > I'll reply to the rest later, after I absorb it. >=20 >>> 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. >=20 > Pedro> This was already discussed. Do I understand correctly that you're > Pedro> going to try to replace gdb_select with gnulib's select? >=20 > Well, that was an idea, but at Cauldron you pointed out that I could > test the event loop under Wine. Also, this week I finally got a gdb > build working on Windows, so I may just try that instead. My thinking > for both of these is that if the code seems to work ok, then there's no > reason to attempt the gnulib thing. Ah, OK. Using the gnulib select would make gdbserver's stdio mode usable on Windows too, but that's certainly not something required for this patch series. Can always be done at some other time. What's the plan for gdb_fildes_t then? Thanks, Pedro Alves