From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 65518385DC1B for ; Wed, 15 Apr 2020 14:13:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 65518385DC1B Received: from mail-ed1-f71.google.com (mail-ed1-f71.google.com [209.85.208.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-461-G00Vgnt3NZefVnhRXvilMA-1; Wed, 15 Apr 2020 10:13:15 -0400 X-MC-Unique: G00Vgnt3NZefVnhRXvilMA-1 Received: by mail-ed1-f71.google.com with SMTP id l25so3093434edt.1 for ; Wed, 15 Apr 2020 07:13:14 -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=u8eNQ8wn+5vH1+TNic2m2TkjHd09gczIOvUxIj2elsA=; b=Bs4cSniON2Q6SgKktAeFJFFDHm53FMBkk8yfOMP5ksiH27OW882W77RLoSFpLhbyal oyHdqutuN1OR97JbPHidNE4GYOhvzwju5UgHlaW3JTOFOJja9FhQ5aIU3LlcXgFTSeaQ YFiD58r2sFr84oSxh5Q7c65uYz7m3Id99fvDO6z53HAu90kSumgFvEjj9V1KOze2GMCO Fj7R2LZJ6idnxHqEQigJTqP8C3o4IBXyELDGaOwzAbpyKK+n6C+Sbj8pogWtSQIXmpBE m2dpPtg3RDuH0v+n8pXflKNp+sFnUQvkaHysCxD4EPeV3lzZrVN2cC9zxeabs0YodVLV LEWQ== X-Gm-Message-State: AGi0PuYSwPpd5hlekpCKuQ5bQzF8+hbS/HaWSMYXhmYcKWNyp4D0EHQO T2bxH+IuqtMO4/mLOidhCGLx9cyNAvpSdHgXmrhKksM+6GI1V4o1zQig0ih/nvqrjWtv3/Je38v rTJtlJeJ0dMGIFGgbvKweyA== X-Received: by 2002:aa7:d056:: with SMTP id n22mr24424204edo.281.1586959993327; Wed, 15 Apr 2020 07:13:13 -0700 (PDT) X-Google-Smtp-Source: APiQypJM9AW8PkyzVzSui++d1Dk0aYcHmQhShDLuVvD7QKQlU+Bh03+KAm18lk6+AsZ6zvjSN6WocQ== X-Received: by 2002:aa7:d056:: with SMTP id n22mr24424180edo.281.1586959993125; Wed, 15 Apr 2020 07:13:13 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id u8sm2128978edx.13.2020.04.15.07.13.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Apr 2020 07:13:12 -0700 (PDT) Subject: Re: [PATCH 19/28] Don't write to inferior_ptid in btrace_fetch To: "Metzger, Markus T" References: <20200414175434.8047-1-palves@redhat.com> <20200414175434.8047-20-palves@redhat.com> Cc: "gdb-patches@sourceware.org" From: Pedro Alves Message-ID: Date: Wed, 15 Apr 2020 15:13:10 +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: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-24.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, 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, 15 Apr 2020 14:13:18 -0000 On 4/15/20 5:52 AM, Metzger, Markus T via Gdb-patches wrote: > Hello Pedro, > >> AFAICT, this isn't required nowadays. > > How is this working nowadays? There are still references to inferior_ptid. Clearly I didn't think this one through. I put a tp->ptid==inferior_ptid assertion in place, and that regressed gdb.python/py-record-btrace-threads.exp. This should mean that the target_read_btrace calls in btrace_fetch can hit the wrong thread. So here's an alternative patch. No regressions when tested with: $ make check TESTS="gdb.btrace/*.exp */*btrace*.exp" >From 92c8fa469295b5737e6cb5e882024af2e9872c4c Mon Sep 17 00:00:00 2001 From: Pedro Alves Date: Mon, 13 Apr 2020 20:02:22 +0100 Subject: [PATCH 19/28] Don't write to inferior_ptid in btrace.c gdb/ChangeLog: yyyy-mm-dd Pedro Alves * btrace.c (btrace_fetch): Use switch_to_thread instead of writing to inferior_ptid. --- gdb/btrace.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/gdb/btrace.c b/gdb/btrace.c index bbf8749649..2964455680 100644 --- a/gdb/btrace.c +++ b/gdb/btrace.c @@ -1908,13 +1908,13 @@ btrace_fetch (struct thread_info *tp, const struct btrace_cpu *cpu) if (btinfo->replay != NULL) return; - /* With CLI usage, TP->PTID always equals INFERIOR_PTID here. Now that we - can store a gdb.Record object in Python referring to a different thread - than the current one, temporarily set INFERIOR_PTID. */ - scoped_restore save_inferior_ptid = make_scoped_restore (&inferior_ptid); - inferior_ptid = tp->ptid; + /* With CLI usage, TP is always the current thread when we get here. + However, since we can also store a gdb.Record object in Python + referring to a different thread than the current one, we need to + temporarily set the current thread. */ + scoped_restore_current_thread restore_thread; + switch_to_thread (tp); /* We should not be called on running or exited threads. */ gdb_assert (can_access_registers_thread (tp)); -- 2.14.5