From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ibm.com 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=pp1; bh=7JhuIZABNQnuEbYlk5DOuEMDTgd0K5VbX34l8jOSfG4=; b=W9a6pgdGoWGbq+h7Xs37m51DgLAKq6vOHX07hzTBpds6v7LegJhWizBUq1gjQTJ+GBkP TEQV4m8AEVtULuZyn816bGvvpBy18La1LwZ2uefutd/tE9QarvNWEAO5qIn+U8pIZEGb cB1CPzz6a3PD/m3JF8X3C3xBXB65OWE0K88ZSM3MLzcaHVdMpdCja6mYTyC3VUrLYeX3 HsiUhC0LSPH6aE3ycv9fp3RQEYSyMJlmDxbyDrfkbTydn/kc40m2kOO6UnXMAyyiMlDV IIDw1joFSHLpzRv7EDUhKc4TFUhLGCxp8XsrLLQCYRaaFVgeeQPFwpGMI5wTJsobWmhX JQ== 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 From: Aditya Kamath1 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?= Content-Type: multipart/alternative; boundary="_000_CH2PR15MB35441FE8F8E1FECD83202EF6D60C9CH2PR15MB3544namp_" 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 X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --_000_CH2PR15MB35441FE8F8E1FECD83202EF6D60C9CH2PR15MB3544namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 --_000_CH2PR15MB35441FE8F8E1FECD83202EF6D60C9CH2PR15MB3544namp_--