From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 0CElB39EfmPPwxsAWB0awg (envelope-from ) for ; Wed, 23 Nov 2022 11:04:15 -0500 Received: by simark.ca (Postfix, from userid 112) id 19C181E124; Wed, 23 Nov 2022 11:04:15 -0500 (EST) 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=g7emoWEx; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 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 5A43C1E0CB for ; Wed, 23 Nov 2022 11:04:14 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id DB168384F4A3 for ; Wed, 23 Nov 2022 16:04:12 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DB168384F4A3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669219452; bh=kZPeEgJqI1N+kyPADx7MrJ9rndK6jjDyUvUkRySqjo0=; h=To:CC:Subject:Date:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=g7emoWExs9bcIZjqfVMnvzepXDWErFuQ23KBMWrxvmcnieY+U3x67u3paf/poLy+3 5o5ixXyN5I6UIFVdVVV6W//sienQI4Ipf23Pf7lopUJtNtkFakKuY37skxbRyszBpJ PVs5ngo++e6jkzuESGCAAAYZh4/bEBVSIOLIhx9w= Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id E42F7386183F for ; Wed, 23 Nov 2022 16:03:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E42F7386183F Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2ANEbf3r023046; Wed, 23 Nov 2022 16:03:14 GMT Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2041.outbound.protection.outlook.com [104.47.66.41]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3m0xw8dsd1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Nov 2022 16:03:13 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RJw7FOYJYHCep0ZKrCzDL539jnBvuFBcVL9e6ME1+2O/y4/BUFB5svGynegpJSrFC+ysy3x+5D5ueiY9QI0F7xbk4TKjy68uNBW6xXQ2Ne1DaYBp0sLlaGerwT54kLhSkwUpFzSE8c2+UmUbmP+YR+g4vaqKgql4JKUpPoEJ2yfrC4pAWvAI3C4/60fJAFaIs6Pg52dwM4ARQoC0hZKaLHiH5+ppsbWwu1UdrH08Mnsiucwid8yNdLi6IxkhDvgyfaY7eVhoTvL90WbMK+Ty9XPykkMg99d6P9fKFGRVvqf0ymPP//j+QyU29oHY8PFZY4x/AXt9XlveTSyIXyIQGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7JhuIZABNQnuEbYlk5DOuEMDTgd0K5VbX34l8jOSfG4=; b=XHT1jJxqAtj/Jk6CUEDqBj7Wxa49n/RwUbTLPqT5/2lyeGE3eSYIUO3PVpCnrrsQ4FbTy5ohZr19AMyyyfYo6F5fZAZZbAEjW9r3QqI9srd8rcXFtEvXX7iBuOp3y4ETNN/QaCfsYdFpVR9Pjey+Nr9YofNZJLes1mOeLcLy867rneTh3mFDH2kool/qNzy+iF1Li7NlLZzjNM4M1GWBp3JfOd7Y9Vqxe61sh7K6dBvgjtwyJgFblIBMGSVPh+aQdwMHnFtVB4XnO2lL+0aind8CyNnl0riM2r7UKEamxt6akRoSQopA8R+HxRjv06v8h/AggqsGb7aeJnNtsDNTcg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ibm.com; dmarc=pass action=none header.from=ibm.com; dkim=pass header.d=ibm.com; arc=none Received: from CH2PR15MB3544.namprd15.prod.outlook.com (2603:10b6:610:5::26) by CH3PR15MB5515.namprd15.prod.outlook.com (2603:10b6:610:142::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5834.15; Wed, 23 Nov 2022 16:03:11 +0000 Received: from CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::9c73:790a:1985:15d2]) by CH2PR15MB3544.namprd15.prod.outlook.com ([fe80::9c73:790a:1985:15d2%5]) with mapi id 15.20.5813.017; Wed, 23 Nov 2022 16:03:11 +0000 To: Ulrich Weigand , "simark@simark.ca" , "gdb-patches@sourceware.org" CC: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Thread-Topic: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Thread-Index: AQHY6DximDPpCqTL9kGyFvcEZokFBq4jlIiAgBFljYeAAA2HgIAIORaygAMrdQCACMPAdYADi8KAgAAbf+Y= Date: Wed, 23 Nov 2022 16:03:11 +0000 Message-ID: References: <0866c91331b08f2870fad6e6a13fbcd1a9823b48.camel@de.ibm.com> <5df6ab523034d1997ffda5bb06c3bd87777dcccb.camel@de.ibm.com> <0dba07cfad3da44c0281c53702d73f807bca7d06.camel@de.ibm.com> In-Reply-To: <0dba07cfad3da44c0281c53702d73f807bca7d06.camel@de.ibm.com> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: CH2PR15MB3544:EE_|CH3PR15MB5515:EE_ x-ms-office365-filtering-correlation-id: 60f06d80-2621-48d0-8180-08dacd6c385b x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wHKDwQqiUHZNAyIj0JqesdqmK8ikl0KlHvThOKWbGrD/FDOQyVfKpt9J2nBu/ZOao4x6LrDOSvUU+1c5WiE5a+DrG2r2xKyw8uOEy3IfZDwfl53ZF5IeqDv6mPS2O5zEH3w9gzPTFmPI2lV/hsjtw5FyP+WtxqCrPqhkozDgSF7r2pHWmdwzzV+1MLdl1U6GU59qMwiLXG4OXGkls/eFwnmv3qTocqg8Hw7J7yUfwOMDkIhSYupq6+QZafqNkXzYI/i3EsrfkUPW7nS0L0ONOVS+EdQXVGRsPSuLRNQDwSXRQvATrDmo0X7TbV+jaxc6ik0F+m9dxDqEkNynQ2w9X7+x9tUSo42zkaLiwGOwsqn1fmAGaS+suZVpE6zH/zjR1I+WTg//xwaB6ZPO0pAlNQXHt6oAwyyQRw3lz1zybo/+j6fe51XMkgQqS5KdySd7HmNVEqw7zTGN4pExMvfIWB1Owp8ZekUDXE1ufDVQxrsGRvdulonq34LNnr/63Sp5QM+2PWFReNXmucYrwESspG7393Jbf4zUCQPKXQhuvm2qKJUxYhhHAdP8NVgNvu3KPiL97CqtMzbA3wJojzkhnYMdhvOpaq2yNGs/vu+RsL45knr4Xkfd01OkzqSA4Ec3Wv73wi1nLlXef9vYXGUyvrFfoGZpZyVbkX5S1w/hZSRO6QjQKnCzoUiJTI6xJz+povq4axCXOVACYav38vGaEg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR15MB3544.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230022)(39860400002)(396003)(376002)(346002)(366004)(136003)(451199015)(9686003)(478600001)(55016003)(38070700005)(71200400001)(83380400001)(186003)(5660300002)(86362001)(6506007)(53546011)(7696005)(52536014)(8936002)(41300700001)(2906002)(38100700002)(122000001)(91956017)(33656002)(19627405001)(110136005)(66476007)(76116006)(4326008)(8676002)(66446008)(66556008)(66946007)(64756008)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?OCXk0SVKSuGux/dmMu+IolHsPtFXs84YaKzvX36/D8xdgEWNKMJfTKV2c+xw?= =?us-ascii?Q?k7llcf4HHzXXTQnrfixKroAPXErGNNvLjA5ZbGeGAZTlWsM2s/5YridqUj5Q?= =?us-ascii?Q?jsE4zCy2CmucYWJF0HKxLNgrTxQ2xBVxipSPBXaYzbdntfmiYt2Ya+MkDrvm?= =?us-ascii?Q?DcHhz9NoHNfHIqK72xAZ+SAiHBLK9iQ92JNweTAuhu1l1lzcVKgACtpM7tBO?= =?us-ascii?Q?zK+Y5JBppR/3I+dVfwaGliOyt2lzMf0eFd2K1aTP55ua/o/S72xP3SRHEvLK?= =?us-ascii?Q?9JxbZVJ4vldtDHdhvhAToMng9NrMMjcsxR56syac6DwuwUQOtUsfTnYCh0ly?= =?us-ascii?Q?GHDMS+K6NN6HJx109gcea1AV2kpDumUHH6jl1NP0cQVy5p89UXtay58sjX9a?= =?us-ascii?Q?N5QGTNqvhWpLiwB0l6zX5X27yQr9G/zaUZZCX0PSxlw1o49qOdZrTuQVNF0a?= =?us-ascii?Q?qHvn5Rc3ApfyfMZ+X8JJCDcp/5hX7n55goHf+AFcpdmYBBHutPqAkeb051N7?= =?us-ascii?Q?w15+IzbX4VywZiJC35iLVo8qxg5475FnXzlgPlLBcElVS1y+DGU/8K+mQvc7?= =?us-ascii?Q?4zpl+Um7BdsEYsGc0Oasn555wVCcGnCZ05Ka52wAPb/hry0Ya2dVux7Rh776?= =?us-ascii?Q?K3roPb3YXfTe/EqMSaZ2LGHLhzE6XSlkX967517BiBs6QVGB1d6IKs8KudOd?= =?us-ascii?Q?sWVLE2N0QFw1GnhtueLo4weCq7CsdYZZ540N3wzG6QmJ1ph346JewtJN0uXN?= =?us-ascii?Q?larU58HEGYmIM1grYBMDbdn0bTCIVP/b9ANKteBwb6pYtW2deXi0kdYxAj1f?= =?us-ascii?Q?kbE+ogttJI3FAElz9aCdZWvo00rEjjoWS6xBHIP066lHAGDebADo/Ts1h+0x?= =?us-ascii?Q?iu4uBTp08y4CH1qJwZDDQmDfddOVjkbfvgkRy5Q0uoxuQK80TAh8usoGasZQ?= =?us-ascii?Q?m4QQIEt+bHusFnw0+1XJYXbp8YSYQr2vcEeNluDaxnJ2/8MEC1sJRnUYYf7t?= =?us-ascii?Q?NicxyIHgHL1Y6YYrFdWdpiRVDGS4fmtz5FmwtykPtmcefbMQUaVl/c3xkjLw?= =?us-ascii?Q?dU7wU95LX7Jxnj4PNX3HIO8XQBbXUBA3iNkiKqXC/nZAQ2754vhUsdqAJKkA?= =?us-ascii?Q?gglyQe+WOVTi29ZDR4O5Q7+SLunDZQ4yvp2qwL2a324XDn9bvxXXwRpgS5xF?= =?us-ascii?Q?zQAuaYXHth9T5ntkCuyLHqKQsKfwbwI55TQ0otvky6MSMH3I3Tivcka/m7IH?= =?us-ascii?Q?X07zVj0a96Bwvm85dPI2sojLPMPdpYouU73ezeQBVV+qwLjKLZQI/5SnjhDe?= =?us-ascii?Q?ErRuPvzVVgYy3z+c/+rw8R8CNtbY3VLgGw+Gh4qnXgUqXJb+N8/+l0YhZ8s1?= =?us-ascii?Q?Y2iDgRyOPCSnhfqXngxe8wBiMUhnMCU4ZmzjcYMMtp54fm4NnRaai22dqDc+?= =?us-ascii?Q?pOqCGU7f/T5nYLuU5a/qGdq3T3ANtudZ8P8ybLoNeaZbOLM5BPYgmE/HlFFk?= =?us-ascii?Q?9/Nq8nEIQJYldn3jtzUJB/9Vic3jJbj8WSLKJAolbDnsNlTm5k/SK/zC0QrQ?= =?us-ascii?Q?rNTU1TN/cSXzVrtLiSP07ZteJBNHsTRIuem4bLjK04soODS2oGTizCgJBioV?= =?us-ascii?Q?1InLpslciu4w2hRFTyTGT7K0Kmku3z45Jb/DyP0jNshf?= MIME-Version: 1.0 X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CH2PR15MB3544.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60f06d80-2621-48d0-8180-08dacd6c385b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2022 16:03:11.1717 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fcf67057-50c9-4ad4-98f3-ffca64add9e9 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ipmyq/9vUFw16d3kkrMmGVWOyD1JUalbMiIfESOy1Jr4ZaM6tar/QpA28sQKSlxpMNyD5FUUNbmqoVeLB4iGuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH3PR15MB5515 X-Proofpoint-GUID: TveRMhypTrTVbJZ7aeSiW0313EuiFaQQ X-Proofpoint-ORIG-GUID: TveRMhypTrTVbJZ7aeSiW0313EuiFaQQ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-11-23_08,2022-11-23_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 clxscore=1011 adultscore=0 bulkscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 suspectscore=0 phishscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2211230114 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Aditya Kamath1 via Gdb-patches Reply-To: Aditya Kamath1 Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Ulrich, I'm confused why this is the correct place. From what I can see, in this scenario, we have: - libpthdebug reports some threads using a thread ID, i.e. pbuf has ptid_t (pid, 0, pthid1) .. ptid_t (pid, 0, pthidN) with pcount >=3D 1. - GDB only has one single thread in unthreaded mode, i.e. gbuf has ptid_t (pid, 0, 0) with gcount =3D=3D 1. So when running the loop, during the first iteration, we should compare ptid_cmp (ptid_t (pid, 0, pthid1), ptid_t (pid, 0, 0)) which should be > 0 since pthid1 > 0. Right? This means we'll get into the branch that just does: delete_thread (gbuf[gi]); thereby deleting the original thread. Does this not happen for you? What is going on instead? [ Note that this is a simplified case with only a single process; in the multi-process scenario, this may be more complex. >What is going on instead? The one I highlighted in bold does not happen. In our first iteration pcoun= t is 1 but gcount is 0. That is why when gi =3D0 =3D=3D gcount becomes true= and control enters into that block instead of going into the else block.. >[ Note that this is a simplified case with only a single process; in the multi-process scenario, this may be more complex. This I agree. I just checked now.. Hmm. So, something is going wrong here.. gcount =3D 0; iterate_over_threads (giter_count, &gcount); g =3D gbuf =3D XNEWVEC (struct thread_info *, gcount); iterate_over_threads (giter_accum, &g); qsort (gbuf, gcount, sizeof *gbuf, gcmp); Let's me check these lines. Hope I answered why I was doing it.. The rest of the changes you mentioned I will do it.. ________________________________ From: Ulrich Weigand Sent: 23 November 2022 19:45 To: simark@simark.ca ; Aditya Kamath1 ; gdb-patches@sourceware.org Cc: Sangamesh Mallayya Subject: Re: [PATCH] 0001-Fix-multi-thread-debug-bug-in-AIX.patch Aditya Kamath1 wrote: >@@ -514,8 +514,16 @@ pdc_read_data (pthdb_user_t user_current_pid, void *b= uf, > during first initialisation. In the rest of the callbacks the > current thread needs to be correct. */ > if (user_current_pid !=3D 0) >- switch_to_thread (current_inferior ()->process_target (), >- ptid_t (user_current_pid)); >+ { >+ inferior *inf =3D find_inferior_ptid (current_inferior ()-> process= _target (), >+ ptid_t (user_current_pid)); This would be simpler using find_inferior_pid. >+ for (thread_info *tp: inf->threads ()) >+ if (tp !=3D NULL) This would be simpler using any_thread_of_inferior. >+ { >+ switch_to_thread (tp); >+ break; >+ } >+ } > status =3D target_read_memory (addr, (gdb_byte *) buf, len); However, switching to just any random thread of the process seems odd. Looking at sol-thread.c, they don't switch to a thread at all in the equivalent place, but rather do this: scoped_restore save_inferior_ptid =3D make_scoped_restore (&inferior_ptid= ); if (inferior_ptid.tid_p () || !target_thread_alive (inferior_ptid)) { /* It's either a thread or an LWP that isn't alive. Any live LWP will do so use the first available. NOTE: We don't need to call switch_to_thread; we're just reading memory. */ inferior_ptid =3D procfs_first_available (); } Since your xfer_partial routine only ever looks at the PID component of the ptid, I'm wondering if we couldn't similarly just switch inferior_ptid, without actually switching theads. Something along the lines of scoped_restore save_inferior_ptid =3D make_scoped_restore (&inferior_ptid= ); if (user_current_pid !=3D 0) inferior_ptid =3D ptid_t (user_current_pid); Does this work for you? >- if (thrinf.ti_cursig =3D=3D SIGTRAP) >+ /* In a multi threaded application user can interrupt the main >+ thread as well. This function should return the tid in this >+ case apart from threads that can trap or be interrupted. */ Whitespace problem. >+ >+ if (thrinf.ti_cursig =3D=3D SIGTRAP || thrinf.ti_cursig =3D=3D SIGI= NT) > return thrinf.ti_tid; This seems an unrelated change? If this is actually necessary, then all the comments (e.g. at the top of this function, or at the call site) likewise need to be updated - they only refer to trap signals currently. > process_stratum_target *proc_target > =3D current_inferior ()->process_target (); >- thread =3D add_thread_with_info (proc_target, >- ptid_t (pid, 0, pbuf[pi].pthid), >- priv); >+ >+ thread_info *tp =3D find_thread_ptid (proc_target, ptid_t (pid)); >+ >+ /* If the pthread library is used then we replace the main >+ with the thread having the main thread ID and process ID. >+ Otherwise this is a new thread and we need to add it. */ >+ if (tp !=3D NULL && tp->priv =3D=3D NULL) >+ { >+ thread_change_ptid (proc_target, tp->ptid, >+ ptid_t (pid, 0, pbuf[pi].pthid)); >+ tp->priv.reset (priv); >+ } >+ else >+ thread =3D add_thread_with_info (proc_target, >+ ptid_t (pid, 0, pbuf[pi].pthid), >+ priv); I'm confused why this is the correct place. From what I can see, in this scenario, we have: - libpthdebug reports some threads using a thread ID, i.e. pbuf has ptid_t (pid, 0, pthid1) .. ptid_t (pid, 0, pthidN) with pcount >=3D 1. - GDB only has one single thread in unthreaded mode, i.e. gbuf has ptid_t (pid, 0, 0) with gcount =3D=3D 1. So when running the loop, during the first iteration, we should compare ptid_cmp (ptid_t (pid, 0, pthid1), ptid_t (pid, 0, 0)) which should be > 0 since pthid1 > 0. Right? This means we'll get into the branch that just does: delete_thread (gbuf[gi]); thereby deleting the original thread. Does this not happen for you? What is going on instead? [ Note that this is a simplified case with only a single process; in the multi-process scenario, this may be more complex. ] Bye, Ulrich