From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by sourceware.org (Postfix) with ESMTPS id C1FFE3857C68 for ; Wed, 5 Aug 2020 22:29:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C1FFE3857C68 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-wm1-f65.google.com with SMTP id c80so7163882wme.0 for ; Wed, 05 Aug 2020 15:29:15 -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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pnPUeMTfgieExTUojXWD3MKo1k2K9igS3Hz+tJWn5Ac=; b=JW4JxcK+9ezoF/3fWB23z08WZEdsXXMZONqgnFH16pNMqFtB3Bdg4fqi1ENbzfUIZ0 cN5CT1rXIe3Ohy81BwhCx46YYoBZbyMIS9bTnFH++FRVkNM2HNea8z8UJgkVur9PMcsN Vw61SvZda7fHwl9U1TBKKV+7zhIfqwCm94SJ0Mfxe/ydwM3mcIpI7P1C+YJAMTWY/Gej LZOu21H7f8UQL2NLYItdtm82ZKaTtK0WIkh+MWaEbjEKDDBlhuQVHyleWcRAQssxc/AX F9cSMVKm5XKoTvNqlC09Ouuan5DLmX4KJ2fbtGbgD8Y9r23/Hhtr34fDI8+8jNFVth4q ZxwQ== X-Gm-Message-State: AOAM5326rNo5TPCKZQqxKcLv432BVJ3nVaVVSuk/8lbE2lTlZ1+FJZ9K iepY0TCTRN/1rYPDVdQgWdLFtEriW4g= X-Google-Smtp-Source: ABdhPJxsB8/r5Jc7VVBdXxffT9ces/JlaFOojHvnWZImd2ywZiA/Z3Y/S7nX/XzM+HtKuaPlBN/Ebw== X-Received: by 2002:a1c:a757:: with SMTP id q84mr4848215wme.1.1596666554845; Wed, 05 Aug 2020 15:29:14 -0700 (PDT) Received: from ?IPv6:2001:8a0:f91a:c400:56ee:75ff:fe8d:232b? ([2001:8a0:f91a:c400:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id e4sm4223898wru.55.2020.08.05.15.29.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 Aug 2020 15:29:13 -0700 (PDT) Subject: Re: [PATCH 3/4] gdb: pass target to thread_ptid_changed observable To: Simon Marchi , gdb-patches@sourceware.org References: <20200720204101.2849535-1-simon.marchi@efficios.com> <20200720204101.2849535-4-simon.marchi@efficios.com> <6bd06f25-c89b-58b5-3639-94813a7284f5@efficios.com> <5e34235b-a256-0255-b268-d929ff2e7a1d@palves.net> <73072472-2115-0c9a-1e28-7b554bc2e4e6@efficios.com> Cc: Laurent From: Pedro Alves Message-ID: <7667e73f-9c79-1913-437d-1b6bc0ec0e8d@palves.net> Date: Wed, 5 Aug 2020 23:29:12 +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: <73072472-2115-0c9a-1e28-7b554bc2e4e6@efficios.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Wed, 05 Aug 2020 22:29:17 -0000 On 8/5/20 8:08 PM, Simon Marchi wrote: > On 2020-08-05 10:50 a.m., Pedro Alves wrote: >> I don't see why we shouldn't. > > I'd say because it's not worth the trouble. But there's really no trouble. > >> Assuming that the regcaches are empty >> like in the current patch can also fail is someone inserts some test >> before this new test that ends up filling in the regcache. I see it as >> your new test being fragile because of that, and running the >> "maint selftest" while some program is running is just a way >> to trigger it. To me, not allowing selftests while the >> program is running is just an admission that the tests >> aren't well isolated enough. >> > > I think it would make more sense to require that each test cleans up > properly after itself. scoped_mock_context creates a new inferior list, adds a new inferior to it with its own test target, adds new thread, and switches to it. The destructor restores the previous state. When we switch to the mock context, the running inferior is not reachable in the inferior list. Whether an inferior was running or not, it shouldn't make a difference. Maybe it should be both scoped_mock_context's constructor and destructor that call registers_changed. But I do think we should put a call to registers_changed somewhere, to maintain invariants properly. > But anyhow, I'll do as you suggest, I don't mind. Thanks.