From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ncgSDjK33mK2VRoAWB0awg (envelope-from ) for ; Mon, 25 Jul 2022 11:30:58 -0400 Received: by simark.ca (Postfix, from userid 112) id 25D0D1E9EB; Mon, 25 Jul 2022 11:30:58 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=NAfW6pDj; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 9EFA11E87E for ; Mon, 25 Jul 2022 11:30:57 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 303313875A25 for ; Mon, 25 Jul 2022 15:30:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 303313875A25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658763056; bh=tdnGnZnf6qJJuyudKCHkON5ubslPt2Pi6Z8KptYajns=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=NAfW6pDj0hDPyLLx+mbpLdEszdNJJccbaZ32/cnwVM/xCJq6Ab5Ss/olutTdCyueR 7zuoPfXo6+hA8NtkfDUasVqrSpfrDNc7lZuRNaRfkiJO3uhS+AZfQjL+hJpVas+sZ7 PaNuQqp4qhlHu3n7a+zEwDsJPMF9fPclMwTBJA54= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 5F144383B78C for ; Mon, 25 Jul 2022 15:30:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F144383B78C Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 00C5E1E5EA; Mon, 25 Jul 2022 11:30:36 -0400 (EDT) Message-ID: <841f0915-13a8-bbb3-07e6-54b5ff4293f1@simark.ca> Date: Mon, 25 Jul 2022 11:30:36 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Fix-for-multiple-thread-detection-in-AIX.patch Content-Language: en-US To: Ulrich Weigand , Sangamesh Mallayya , Aditya Kamath1 , "simon.marchi@efficios.com" , "gdb-patches@sourceware.org" References: <49119016e80e58fafea0248887148aca3d1aef8c.camel@de.ibm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-07-25 08:21, Ulrich Weigand wrote: > > Aditya Kamath1 wrote: > >> The cause of the bug :- Since, for the GDB core we are >> switch_to_no_thread() i.e. we do not have a thread till we return the >> pid from the wait() there is no thread. So, when a call is made from >> pd_activate() in wait() of aix-thread.c, to pthdb_session_init() we are >> going to recieve PTHDB_NOT_THREADED. > > Thanks for the explanation. I wasn't aware the use of > inferior_ptid happens in some of callback routines used > by the pthdb_session_init() library routine. Thanks, me neither, but it makes sense. > I still think the proposed fix isn't really ideal. Can you instead > try to *temporarily* (i.e. using a scoped_restore) set up inferior_ptid > in pd_activate() before calling pthdb_session_init(), with a comment > explaining that this is needed for the callbacks? That sounds like a good idea, this way, from the point of view of the caller of pd_activate, pd_activate does not care about global state. That's how we can do baby steps towards relying less on global state implicitly. The next step could be to try to make each individual callback switch to the right global context, based on what they need. You just need to be careful, some parts of GDB expect inferior_ptid, the current thread, the current inferior and the current program space to be sync'ed. If you just set inferior_ptid, you need to make sure to only call functions that use inferior_ptid, not the other current stuff. There is not practical way to know this, you have to carefully inspect what is called. To avoid this kind of problems, you can temporarily switch thread (using scoped_restore_current_thread + switch_to_thread), which will set all the current stuff mentioned above. But sometimes this isn't possible, especially in thw wait method, because there isn't always a thread_info for the ptid you are handling yet, so you can't switch to it. Given the AIX target only supports one inferior for now, the current inferior and program space should be correct. But to support multi-inferior, it will be important to keep that in mind. You might have to switch to the right inferior in addition to setting inferior_ptid in pd_acticate. This hunk in the patch: diff --git a/gdb/aix-thread.c b/gdb/aix-thread.c index 4c9195a7f12..91466a17647 100644 --- a/gdb/aix-thread.c +++ b/gdb/aix-thread.c @@ -976,7 +976,7 @@ pd_enable (void) /* If we're debugging a core file or an attached inferior, the pthread library may already have been initialized, so try to activate thread debugging. */ - pd_activate (1); + pd_activate (inferior_ptid.pid()); } looks right to me (except the missing space before the parenthesis). It looks like an oversight in my "gdb: fix {rs6000_nat_target,aix_thread_target}::wait to not use inferior_ptid" patch, I forgot to update that call to pd_activate. Note that the old parameter to pd_activate was SET_INFPID, and if set, pd_update would change the current thread to reflect the thread ptid, if thread debugging was enabled. The current code no longer does that. If that was important, we can re-introduce it here: make pd_enable switch to the thread with the ptid returned by pd_activate. Simon