From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id TH3pM/bFhV/2CwAAWB0awg (envelope-from ) for ; Tue, 13 Oct 2020 11:21:26 -0400 Received: by simark.ca (Postfix, from userid 112) id C6FC71EF6F; Tue, 13 Oct 2020 11:21:26 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 062CD1E58E for ; Tue, 13 Oct 2020 11:21:26 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6CFEA38708B9; Tue, 13 Oct 2020 15:21:25 +0000 (GMT) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by sourceware.org (Postfix) with ESMTPS id 2138D3861817 for ; Tue, 13 Oct 2020 15:21:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2138D3861817 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=alves.ped@gmail.com Received: by mail-wr1-f66.google.com with SMTP id s9so12434809wro.8 for ; Tue, 13 Oct 2020 08:21:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=IlJTPArfT8BgrpPnkCp6V2lp2W4jH2yLoysxnWAXpAE=; b=ic3sc8+J6NN6L4K440CoCzLAZOzlcmFnuC+jL7p1a5Kq71No4/EiIfmi9YuMtlUtWH oqnrs/ZfTQJTi5XOUoGUllLWGu7pkCTusUQb3UmLFRck9avqyz/xYryqJz9lY2/n749i yye7a8r0jGPao/YZoreWZcbTEkGaeHSsDfVev5qbzjobVZZ5gSNtFM+Uxq84+ywHhbqB dTLCAP/UvxV72Gf2eGTJum6JaG7QWUP7p2Oj417n4sIUQJHNesvX2bHv2bziCYbiYckQ BeZTSMDmOCvxLCHdh0/mWYSIfL1Re984kZ62dwFkh8B8ojLkSLWEIWgZbC9+ynLOm1z4 t2vQ== X-Gm-Message-State: AOAM531Spfy3ggyirQIFgHsFEFxkOU2gdFzLezU+SmM+QOLlhrBClxcP P3ysz++FlPW1ZfATVrn7Sc4UEE2U5Flqcw== X-Google-Smtp-Source: ABdhPJzfo+TIexrttjhFAMrIZ6qQSOxKVZTzg4Y/aoKhysuUcJVxaavVTOZORZHa3qk4Rr6AZMACzQ== X-Received: by 2002:a5d:6a4f:: with SMTP id t15mr201992wrw.126.1602602481449; Tue, 13 Oct 2020 08:21:21 -0700 (PDT) Received: from ?IPv6:2001:8a0:f91e:6d00:c80a:ea25:47ef:5f73? ([2001:8a0:f91e:6d00:c80a:ea25:47ef:5f73]) by smtp.gmail.com with ESMTPSA id w4sm83619wmi.10.2020.10.13.08.21.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Oct 2020 08:21:20 -0700 (PDT) Subject: Re: [PATCH] gdb: don't pass TARGET_WNOHANG to targets that can't async (PR 26642) To: Simon Marchi , gdb-patches@sourceware.org References: <20201001025656.2561757-1-simon.marchi@polymtl.ca> <2fc59140-0fb4-cab3-a816-2abc95116387@palves.net> <518fc763-c94d-c987-0bc8-0be3c2e3a6f6@polymtl.ca> From: Pedro Alves Message-ID: <9ce07de9-7945-bc5c-e49d-700062e44e2a@palves.net> Date: Tue, 13 Oct 2020 16:21:18 +0100 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: <518fc763-c94d-c987-0bc8-0be3c2e3a6f6@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/13/20 4:06 PM, Simon Marchi wrote: > On 2020-10-12 10:48 a.m., Pedro Alves wrote: >> I'd rather go without this hunk. Would it still fix things? > > Yes, since infrun won't ask linux-nat to TARGET_WNOHANG when > target_async_permitted is false. I'll remove it, since it can never > happen with the assert in target_wait. If anything, we could put an > assert here as a double-check, if you think it could help. I don't think it could help. > I'll send a v2 shortly. > > I was wondering, do you see a better way to fix this than what I did in > do_target_wait_1, forcing TARGET_WNOHANG to off? It doesn't feel right > to have the caller ask for something and just do something else. But I > couldn't think of anything better (that's also suitable for the release > branch, at least). I don't -- you can't do it at the caller because there you don't know which inferior/target will be called. We could just change the semantics of the do_target_wait slightly, like: static bool do_target_wait (ptid_t wait_ptid, execution_control_state *ecs, - target_wait_flags options) + bool dont_block_if_possible) { That doesn't seem that much better to me, though.