From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [207.211.31.81]) by sourceware.org (Postfix) with ESMTP id 65442385B835 for ; Fri, 17 Apr 2020 16:46:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 65442385B835 Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-327-l72xFpJeMoe72ulD1r5kwA-1; Fri, 17 Apr 2020 12:46:12 -0400 X-MC-Unique: l72xFpJeMoe72ulD1r5kwA-1 Received: by mail-ed1-f72.google.com with SMTP id v18so977543edr.15 for ; Fri, 17 Apr 2020 09:46:11 -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=xdb+NOG92NblzG5bKVi7gGtQCbS9func62xGQhkee0Q=; b=SoRVkq+v/3uQIkKeOUIgUq/5nofFi3lb+b3KoOky4AWlm0c+Eg0PwX9ownc89SGqe8 0na1ld0gWaZDa8bAQeC9k4pFpSwaYcI0kxZtHLbxz2vypBVdaGBhNm263eD8sdSSFkpb 5X9O2jOvB4Emy9/1HVxj0PSZXuCmFqJ9m9SmU2NL6955fAi8PTU2MowFBv7bFfVlh4CZ t34vt0X/20XLnAb2r3nBjQZ4uPPmZwXUJVUNLZbkMiTf4fuld3qOMOVT9cXEcLnoDRE7 PES+kai7Gnd7o/65hNXfgeITBaqCkGLdhlgz1p/YvraWdnS6tpm/D9Ulby2OXqZ0Jprs jkCw== X-Gm-Message-State: AGi0PubuNxqUPiEzAJ7H7Vf7dqfEEGR4NKGZI3jzK7wWiwqt7hx2CeUZ fQGvl1ypC53wkxBvzvst9kJ+gePQX1De8P7VawTsBDoWhwnG5KU1h3xqIe+m2Fc30IjUMQE0kv4 2KKNCW9OqKudbq7vP+GYVeA== X-Received: by 2002:a50:81c5:: with SMTP id 63mr3795607ede.115.1587141970694; Fri, 17 Apr 2020 09:46:10 -0700 (PDT) X-Google-Smtp-Source: APiQypI4TnNJhebPBco0BGFUrHbkcpQVdlMa33NwpiAYMHWXolfZUpzwjGVU5NEziTVi6kibu29ohg== X-Received: by 2002:a50:81c5:: with SMTP id 63mr3795579ede.115.1587141970392; Fri, 17 Apr 2020 09:46:10 -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 w20sm3556139ejv.40.2020.04.17.09.46.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Apr 2020 09:46:09 -0700 (PDT) Subject: Re: [PATCH 28/28] Decouple inferior_ptid/inferior_thread(); dup ptids in thread list (PR/25412) To: Simon Marchi , gdb-patches@sourceware.org References: <20200414175434.8047-1-palves@redhat.com> <20200414175434.8047-29-palves@redhat.com> <4f6c2c52-2fbb-809f-693c-8ae87d2b8549@simark.ca> <91101152-59ee-4f6c-07d7-20bec5c76b7a@simark.ca> From: Pedro Alves Message-ID: <8f5ee438-fb09-cdf1-326e-499875fcbb6a@redhat.com> Date: Fri, 17 Apr 2020 17:46:08 +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: <91101152-59ee-4f6c-07d7-20bec5c76b7a@simark.ca> 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=-10.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Fri, 17 Apr 2020 16:46:28 -0000 On 4/17/20 3:06 PM, Simon Marchi wrote: > On 2020-04-17 6:29 a.m., Pedro Alves wrote: >> On 4/16/20 9:38 PM, Simon Marchi wrote: >>> On 2020-04-16 4:12 p.m., Pedro Alves via Gdb-patches wrote: >> >>>> How are you making sure that iterating the threads walks them in >>>> creation/insertion order instead of ptid_t order? >>> >>> The only spot that I found the order mattered was precisely for "info threads". >>> There, I gather the list of threads to display, sort them by per_inf_num, and >>> print them. >>> >>> https://github.com/simark/binutils-gdb/commit/25c67729996dc83912d34a5901016404b3638bc1#diff-5479a5443dca2232f8552dfb5b30ac3dR1104 >>> >> >> Hmm, OK. I'm not 100% sure that's a good idea; it makes me a bit nervous >> because I'm not sure if this has an impact on run control. Something to >> think about. We could instead have the new ptid_t map for ptid_t look ups, but >> still also maintain the linked list in order to walk the thread list. (That >> would also be a much simpler patch, I think.) > > I also thought about that as a backup solution. However, the testsuite didn't show > any more regressions, so I stayed with just the map. Maybe. Though, this is likely to make debugging gdb harder, both interactive debugging ("p thread->next->next->state" kind of things), and also infrun logs -- The order which gdb resumes, suspends, etc. threads will change as threads appear/disappear. Sticking to creation order is likely to avoid headaches, IMO. Thanks, Pedro Alves