From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6WW0Al2AqmovMxIAWB0awg (envelope-from ) for ; Wed, 16 Sep 2026 07:41:17 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=PIvkW0FE; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 05B361E06B; Wed, 16 Sep 2026 07:41:17 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2B64F1E01F for ; Wed, 16 Sep 2026 07:41:16 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8CCAD4BA798B for ; Wed, 16 Sep 2026 11:41:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8CCAD4BA798B Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=PIvkW0FE Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 2DDAE4BA23FF for ; Wed, 16 Sep 2026 11:40:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DDAE4BA23FF Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ibm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2DDAE4BA23FF Authentication-Results: sourceware.org; arc=fail smtp.remote-ip=148.163.158.5 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1789558843; cv=fail; b=kKtrFOHonirGBZBkEcXNodm3gnefiGFAxshimnh5cg6w4suWnKM8xnVivRsSj0Nh2T6rmlrbQ1kgFjVI+i8+U5Yei1VJy/JQAfr92Qxn5wwwOznV+cPx4U2+lrYary1i34Zp6k73jiVIeCA+Ma6k9lb4lSwlSuL/oiLVjo2eSc4= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1789558843; c=relaxed/simple; bh=6H/47EFlytK/0iUl4BDdgCUSGkj4WExIXVLj1uUdxGI=; h=DKIM-Signature:From:To:Date:Message-ID:MIME-Version:Subject; b=pHrPpFI0L3gj4v/2BcUV+DLdWNVESCEyqRSgx2rR/suJOFlSFeR8GI//yA8FPq9qoSl8OS9Yn30yrto37Ovkv5v9O3xOlPJSRC6DM/lVvkHWDFwB9Ywjjzqi9DdrYQm6Xd8oDehamLeyeBLEFHErHm1nC8mz30LEAufI6JNZruc= ARC-Authentication-Results: i=2; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=ibm.com header.i=@ibm.com header.a=rsa-sha256 header.s=pp1 header.b=PIvkW0FE DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2DDAE4BA23FF Received: from pps.filterd (m0353725.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68GBCfni791596; Wed, 16 Sep 2026 11:40:39 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to; s=pp1; bh=q29Lurm+Qr3Yw8PajbHukzHl9hO/FL HVlT/kUIKlCOs=; b=PIvkW0FEEL1R1dxj3jJWlogjhZMXhLRadh/+vJ43sJpvTx Gm/p0SXXyjJpAz1dIrlwvXS+n/hD8cgWejMDsCBs3r8nMCQD22BfEQgCUi2MX2y7 CyxRFuU4AQTcTqvjoujWmajcmdPqH4/t+WqNCxhZtmph+wd3eSJeYMge6jGFXzxa XItM3eZmMmetY0oZ6Li5kgCZqkYuo+R+pyCTR65c6foA9BrbCUxUkZc24gHWNXTH /3RKougxBPvsrD/Xa6RfH0IBQK1dtIh7JCctGuehlIGAFDM5I8sTnJniwl+MCX9o lc79Ljl3GB46aK30haoC4r0yfK+OiJdYeuUr/lTQ== Received: from sn4pr2101cu001.outbound.protection.outlook.com (mail-southcentralusazon11012002.outbound.protection.outlook.com [40.93.195.2]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gmw5e40y0-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 16 Sep 2026 11:40:38 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=duZ2Cr5KiOrEGP4L97gyns9BkC2P1T/HDooRP+gmJS3OX2xxJF6Gi7tZL8Sb0lSrbCqgiAuN+qZYDmbTi+w0SL+hUw/I1pCPRS6tp03gfktOSHh9uV9BPFy5eRqBGYeINruyOAVi09la+Fr+ZUf3cclzswtXOkVliOdd+wpwT5WQYxEJO2ofeHkE8ZLRfYnaflYsOIUMiWuQpWUP3QgqRUXENhjsige2nIQWahYfbVRU0ViwgPyrkGn4YVaZh1vNbUqZzkpmS5WW2LaFQv3HLOW+/WO8fQ1tkc3fufM18RRainPuQUYahWYo+m/Cza+RkejWSc8mR2d/fNXUIv7g/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=q29Lurm+Qr3Yw8PajbHukzHl9hO/FLHVlT/kUIKlCOs=; b=EoT7m6IfPVOM/xUqV5DQEIiPRC/I6kG3Tpo+IPsndFFxYFdMpPHpdKBvsGtnZVdEos2AK1R71WOss6POVOMLtJTzUSWfRKbFY0cgzh9PPrCksTGS7DJNUCe+iJByCgdM+FemrSqao23m/OB2zpySYOVebz2oxqE9k0JpcSHTemjGE2hvbpl9kgkpUFgfPbVbUhMUuXbQ8A2/zodGOvMVUYZfsmXxjlN4ohJy6hn78qH4xG2heYO15CgdCnUxmMbkz/pja+xEM8MtW7Zvvv/SfK2mwONbN4N/xP2/Cg71RyqEfqUHdGQjRlHIhRTPzoI/Xs6zMd1A0k+ZevOBdhOkjQ== 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 SJ2PR15MB6466.namprd15.prod.outlook.com (2603:10b6:a03:56e::15) by DM3PPF70060AA38.namprd15.prod.outlook.com (2603:10b6:f:fc00::41e) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.12; Wed, 16 Sep 2026 11:40:36 +0000 Received: from SJ2PR15MB6466.namprd15.prod.outlook.com ([fe80::6fda:46c:feee:167c]) by SJ2PR15MB6466.namprd15.prod.outlook.com ([fe80::6fda:46c:feee:167c%6]) with mapi id 15.21.0406.007; Wed, 16 Sep 2026 11:40:35 +0000 From: Aditya Kamath To: Simon Marchi , Aditya Vidyadhar Kamath , Ulrich Weigand , "tom@tromey.com" CC: "gdb-patches@sourceware.org" , SANGAMESH MALLAYYA Thread-Topic: [EXTERNAL] Re: [PATCH v2] Speed up next/step while debugging multithreaded programs on AIX. Thread-Index: AQHdQSfuvploB3+NYU6md0Ij7q1He7bPoLBM Date: Wed, 16 Sep 2026 11:40:35 +0000 Message-ID: References: <20260910101643.85955-2-akamath996@gmail.com> <13694747-63ee-44a0-ae1a-fdd1527dd009@polymtl.ca> In-Reply-To: <13694747-63ee-44a0-ae1a-fdd1527dd009@polymtl.ca> Accept-Language: en-IN, en-US Content-Language: en-IN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-reactions: allow x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ2PR15MB6466:EE_|DM3PPF70060AA38:EE_ x-ms-office365-filtering-correlation-id: 6a2ea21b-ee14-4385-9675-08df13e752df x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|23010399003|366016|5023799004|10067099003|56012099006|4143699003|11063799006|6133799003|3023799007|22082099003|18002099003|8096899003|38070700021; x-microsoft-antispam-message-info: fslT0Gj+aaFPIBdIU89B/NjgGZd0v5XaKcxGfB7rw1RDPNLy/eTH9VHN25B3zaAuauQPzKNE1k6eh84bRgoP04AnhGJrF/46Cihc0xOUQfh6RGrc0PRqwmW1fSBqU8W+YNYHGdg/Dv4ESk7lLoBxeufiJ5nQJK2Evb6nLjuu0i8G9pkP/m1FgMSoMhMLBqART9mB8/ZOzYAzUd/JYREhsyro5w4apLN+/K6MGmkBblj4X5D+RBmFWYTJDmUnT1AH4Vgv8t/ZtubO9fLk8G7BNFMB9emCI/EOm6zvTKeeWnk2EGKk0jF93bIRkpvBbBMM3iQAky6aLLTXeTTu+XabXwA8OZjd1sZHWSmeEP/Mwvb2LZAn4nC6gFJHMSgtJ5PBBgXJV3mLy9g0g4xDi49RNya+H0X25ldX1dR2qh3CWe39XRYSpl8XWBSRj2rQDeVJP+c+lR4puZsWKronf5lg26Cozey/sveXjJLJqbBW2FUjVrWf7pwDk77hsyMygVpMsVlqYF8uuLb9THA52H56mp2jb04UW9OcwdVUDePPLIgXTxLx70lhwmqJYPyqkz3jE4UAvHTgS6UFxwQDwfdGk5ezXIPDrvZ9nSHl4F8mqseYyKLlmOMwqbiC6IJdTZWQca5KIZwClmzr1CHmSr+SSTuvMkz2+jM5gq8j6Byydr93K4mS5YV1djtZIlgI+HjwRuR641Zt/rRF8PiDIfUkHV3mZpKLfrXt3eyxgRXyDOY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ2PR15MB6466.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(5023799004)(10067099003)(56012099006)(4143699003)(11063799006)(6133799003)(3023799007)(22082099003)(18002099003)(8096899003)(38070700021); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?p/IPfwCZB2d7nmZIlMYj6wR6uZC5EFqHMZAjTjYD/m8Y/B5KZA8EUzMf98M5?= =?us-ascii?Q?DZAZXD7+JWH52UkxGVWyeWsc987FGlEOMuWuXM1ldpPHYX3bpzPxtCxL1Mzn?= =?us-ascii?Q?W1bT23vFSgQeGeHI3j6w12qOyi+YPYTsmSuMWNrXP0/MDGqqX6PwMSxBHW5M?= =?us-ascii?Q?nMAkgejCgz4dLACcZhEJfCg/gS4reOippN7Hm7pzmnMCxKSw+XBEc20ubtdw?= =?us-ascii?Q?8ldkWLbjPflreYmQ+ygUnO4Jck8SePZ2SD6f7Ect7nlQ0QNXS/LOuR69wRwL?= =?us-ascii?Q?NT3JvmMr8bAEnIYEupcFmEoCNdDDNyBqWLhPONPLLdOdXPP/NjOEj8YWaCxe?= =?us-ascii?Q?bkFhIaxqBNjC49AdAu3uqEBsnLMITVQcc/IAEjcTaTaBYDrZNt/hlnAr54Yn?= =?us-ascii?Q?rTYjYh9OWFNOhtFK4CXdL7E+PQLMKO9/gcTMfhbYu/Kv//K+FC/dTbAWYAzp?= =?us-ascii?Q?01k8vhQzJbuhIcKi/sTxsVy06/C5r3ODqS00WTQkCz8fzTdvuzY9p5QLniGX?= =?us-ascii?Q?ImCs9R74dkFEnE2LoQqLw1I8Vd3kjbHr25oOaSQmiIZ3MSHd6QBKgsYQbBE8?= =?us-ascii?Q?axRwpiF1Lh2Z7KHn43h959RAhL4/dWn00gy4WNOSUhD/8mv45e9jx6FqswM8?= =?us-ascii?Q?NTtL2x/SKeaxhd8d/QaW2iaMfMzUGSRrLXTM6coE0yExYvXiCIjEnYooqhIL?= =?us-ascii?Q?sf2s4ZpfqwuckeOr8jbK9ayPrxXuSToriouVRCU4uhZ2KVJ3pFj70VwgzoRM?= =?us-ascii?Q?z+1wjtVqFu3RDx7tQudW4gkRYzCufbUJf+j4JGj98+a7WkblZYxXLNwRJMSG?= =?us-ascii?Q?ctOpbm1qPRp029tbAAUZg+Gt5BVd1f9oBBBSykis5EY+H5Jr/ibELrRKc5m1?= =?us-ascii?Q?WM7xUAN+2kfxhBFVwk2zVNQOP3SzbLpVuLz6/uqoWWZlDo7xFwHvQmfnsrhC?= =?us-ascii?Q?pw3xcumLmvuZoc47xUAqNsm5SQtcQ0bRTSQVxp6xVq3jtODndeQuwwV7tN5H?= =?us-ascii?Q?4n1RInjW5L0v7puC1IqEaZROCYEUOLtUIkiRyN/+fxEzRrG9eHESRY3J1gGx?= =?us-ascii?Q?C/E8F6GDWQeGyxzS71xC/6db4NnRrPbqeLyUZazmb/cbv1tCRYz16ZU61QFr?= =?us-ascii?Q?nrQQDVL9ApOFG4rKxro26JFVMhhnJUQXZsJvPayyLGDrsjWVAS+gs51s6mOo?= =?us-ascii?Q?FCEitPtp9FQTu6Umbvt1m2bAb467cA+aj4ePKHpiDkfLMnIVWh7l5DPxufj4?= =?us-ascii?Q?c3PXL/Gztje/Wi4WFwRVw+y5Tkl4IC/RKSW0+5MNsMLkJGL31Jr+16kR2AZK?= =?us-ascii?Q?s9ZNoVkzLhelROa27sKv9c5gJ49WqmFdkae7ihsFuc/Zzfyh8l5OlBehVKQ0?= =?us-ascii?Q?GQpiqvz9nML9VIZoSa6ZttcgY9+47WFcHI7vOTgKi8p9rEX6xBuzc2fXRhbu?= =?us-ascii?Q?UaKtzRMqiDLpzfaPiMO1h5XoE9H9iAbOqdRcTwtF+XIj2EvO/jZptWDdyegB?= =?us-ascii?Q?zqUC9tIAtZw/MdAv9r6U5PXN/8TKnRnH1IjsBFdNOYy3IHUECvVItHzQHeWn?= =?us-ascii?Q?XIv9k5T8DRDkD6vSOJALmKCEVb/fStO7wGa94E8IkxfVqiwEMACz4Ol2TvxY?= =?us-ascii?Q?IY95mjApDV3DPLnOd/mErr3ksZ5xmVTblKsVqjNP0+0+uqFlt7u7INzTCeo+?= =?us-ascii?Q?Qa/Nnrf4g7QrFFdfuNCXb7VUs7BQenO9SE81EEf4P0EgMU6a4da1VVKxGrWd?= =?us-ascii?Q?bXoipMxV57Cy36ea6L6KwVKQwg1KOCk=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR15MB6488198E4B3AE10E92164289D6BA2LV8PR15MB6488namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: ujSQP2eF7Me33ELkxul2CCbM8fO8RtR3x2sCzw9EgROlHXjmhcQFqruemx9+WgZF3z1VHdfqIaqZ9j8Pq9/glZK9QsY2UOZLDbwlAVcVGqX+JMt98qKWDMbEu0tlGaZRCcudhfB52YKcyQBCzdHzQYZ/a1+WRVoSIBqT9keX9pNIN6PfHQjENO+a+gOWq9IQGR5BRC49Z36oFucQFBYwql/qRx+IBz+efY1Dbq2JQcUExRlMp7qIIuH2aDPWZ0LMpDZSCyJrnT/r3zucb6iHRET53yreSaShJiz5eaUacYR9Y7fuxZD8UmqlMYQ8HLpz++r6nrhzAJtQqySCmUBYNQ== X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ2PR15MB6466.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6a2ea21b-ee14-4385-9675-08df13e752df X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Sep 2026 11:40:35.8345 (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: UKyT5dMiQLOkRzB9VS8NM+SDHe3A+1gsICvLGqjav8MwcYZ1SCLrRhmCrUvsWug8zREO7Kz4OeNL7A4viSs9qA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3PPF70060AA38 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTE2MDE1MyBTYWx0ZWRfX3dyfOJiUotPF Y3WvRI+pMCAM4vuAUwlafrlb0icG0OUOShP7O3jIoABhCalZVuXMwXFGXoOltS2+iDgzO09qioQ kLYBC+NHBiPnqM12XZeaPb96fj1+qMROfmv7ohi5T/WXFSx+oLeqON9cPzevjw2dHAwLx6s9T6i z8np9ho8jiD3+cJ+U4mr/Bg6eXwPWNuN5YIZGwSGf9XTjzcK3PgOowHMFcBuXaHKhQmGmMUP3zI UNgzzTmQmb18r0MoVIJ7lWiqYcokNWLlMNRH6S2HGhRxig5uyoMOaIGuGWp82oJm262Oh2AYfaw j0EjTykW3GBYwgsCZownnmww7uf7REIsrR1yCxWTujhLzPPnYSAWVMMzXRR/V03KDiAQ5Ce+Mhj K3BEnz9V/0zKDVKdZ4s+MgehFnbC5ur753ZSu5/pw7/wbe3dNnugzcyobooU7OofJDehYj7itK3 oAkLtcLDHHngCfMudGQ== X-Authority-Analysis: v=2.4 cv=E/NYNqdl c=1 sm=1 tr=0 ts=6aaa8036 cx=c_pps a=LBR8CsJoUNkXwF8+XrmcNA==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=V8glGbnc2Ofi9Qvn3v5h:22 a=KsXH65t4hV730UeiS10A:9 a=CjuIK1q_8ugA:10 a=NPzaXmaBK8hI9ljJ-xgA:9 a=K2u5cFIIuJsmeTdd:21 a=_W_S_7VecoQA:10 X-Proofpoint-ORIG-GUID: E20gq7CyDt4Af3Ctg1VHCVDiuxiWBwYa X-Proofpoint-Spam-Info: AW1haW4tMjYwOTE2MDE1MyBTYWx0ZWRfX4usWBEdo9HyK Et0M01uvjWhYP11hN9m8Nw73F5tVjuJj/Hx36rKetqlgKFt7+XBI+tbDgmbGps7ZEbLzrmJypeo ohWFl9XGPkjCP9tvfKAm5tuumQ7MeQ0= X-Proofpoint-GUID: T0rlL1wStD5aNJHg9UiDLA1MWZTxdO-2 Subject: RE: [PATCH v2] Speed up next/step while debugging multithreaded programs on AIX. X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1176,Hydra:6.1.134,FMLib:17.12.100.49 definitions=2026-09-15_05,2026-09-15_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 lowpriorityscore=0 priorityscore=1501 spamscore=0 adultscore=0 clxscore=1015 bulkscore=0 malwarescore=0 suspectscore=0 phishscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609160153 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org --_000_LV8PR15MB6488198E4B3AE10E92164289D6BA2LV8PR15MB6488namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi everyone, I am sending a 3 patch series to address the concerns, Thank you very much = for the review. Here are my thoughts. >> per step when program has atleast 3 or more threads running. A simple >> walk through a function took around a minute. In compiler codes this is >> slow. >> >> TO measure this properly I wrote a benchmark pasted below. The program s= pawns >> 20 worker threads , then stops inside a function with 10 simple >> that GDB steps over one by one. The GDB batch script breaks at that >Seems to be missing a word after "simple". Statements? Made the corrections. >> None of this work is wrong but it is needed when threads actually come >> and go. But during a next or step sequence through a function, the >> thread list does not change. Paying for a full rescan on every stop is >> something not needed I think. >I mean, it *could* change, you could do "next" over a function that >spawns a thread, a background thread (one other than the one you step) >could spawn a thread, another thread could have exited, etc. Yes, in the v3 version I have handle this. GDB resumes all threads (to let = the callee execute), using ptid.tid() =3D=3D 0. That path in resume() sets = last_resume_step =3D 0. So when the return-address breakpoint fires, step_s= top =3D false and the full sync runs and any new thread is caught. >It's unrelated to this patch, but I happen to be looking at aix-thread.c >because of it and I must ask if these things are still relevant, given >the AIX versions and configurations you support nowadays: The first patch in the coming series addresses these. Thanks for pointing o= ut. >Ulrich already pointed out that you could have one thread appear and one >disappear, and the count will not change. Yes, this is something I did not think. Thanks to both of you. The v3 patch= implementation is based on single step only. No thread counts used. >So yeah, what about doing "next" over a call that spawns a thread, or a >background thread existing while you do a next? The fix is safe for both scenarios because step_stop=3Dtrue is only set whe= n software single-step breakpoints were inserted for the resumed thread whi= ch means GDB knows the thread executed exactly one instruction and could no= t have called pthread_create or pthread_exit. For next over a function call= that spawns a thread, GDB resumes all threads (ptid.tid()=3D=3D0), which e= xplicitly clears last_resume_step=3D0 at line 1087, so step_stop is never t= rue and sync_threadlists() runs in full, picking up the new thread. For a b= ackground thread exiting during next, the single-step skips only apply to t= he internal one-instruction steps of the stepped thread; as soon as GDB res= umes all threads for the next source-line boundary it clears last_resume_st= ep=3D0, so the following stop calls sync_threadlists() and detects the exit= . In both cases sync_threadlists() is always called on any stop where threa= d population could have changed. The optimization only fires for stops that= are pure single-step traps of a single thread. No new thread can be create= d or destroyed in one instruction, so skipping the session update on those = stops is correct. This is what my thought process is. >> +/* Number of thread descriptors to fetch per getthrds() call. The orig= inal >> + code fetched one at a time, which costs one syscall per thread. Fet= ching >> + in batches reduces that to one syscall per GETTHRDS_BATCH threads. = */ >No need to document what the original code did. Just keep the first >sentence. Sure, corrected the same in second patch of the coming series. >> +#define GETTHRDS_BATCH 64 >Prefer: >constexpr int GETTHRDS_BATCH =3D 64; Done this in v3 version of the patch. >> + >> /* Search through the list of all kernel threads for the thread >> that has stopped on a SIGTRAP signal, and return its TID. >> Return 0 if none found. */ >This predates your patch, but is the comment for the get_signaled_thread >function accurate? It says it looks for a thread that has stopped on a >SIGTRAP signal, but the implementation seems to look for any signal, not >just SIGTRAP. I have corrected this. >> - while (1) >> + while ((count =3D getthrds (pid, thrinf, sizeof (thrinf[0]), >> + &ktid, GETTHRDS_BATCH)) > 0) >>Prefer declaring the variable in the while statement, and separating the >>comparison from the assignment. This should work: >> while (int count =3D getthrds (pid, thrinf, sizeof (thrinf[0]), &ktid, >> GETTHRDS_BATCH)); >> count > 0) >> { >> + for (i =3D 0; i < count; i++) >> + if (thrinf[i].ti_cursig) >> + return thrinf[i].ti_tid; >Declare variable `i` in the for loop. The above two are addressed in v3 version of this patch. Simon, that works = with for loop and not with while. Have a nice day ahead. Thanks and regards, Aditya. --_000_LV8PR15MB6488198E4B3AE10E92164289D6BA2LV8PR15MB6488namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Hi everyone,

I am sending a 3 patch = series to address the concerns, Thank you very much for the review. Here ar= e my thoughts.

>> per step when program has atleast 3 or more threads running. A sim= ple
>> walk through a function took around a minute. In compiler codes th= is is
>> slow.
>>
>> TO measure this properly I wrote a benchmark pasted below. The pro= gram spawns
>> 20 worker threads , then stops inside a function with 10 simple >> that GDB steps over one by one. The GDB batch script breaks at tha= t

>Seems to be missing a word after "simple".  Statements?<= /div>

Made the corrections.

>> None of this work is wrong but it is needed when threads actually = come
>> and go.  But during a next or step sequence through a functio= n, the
>> thread list does not change. Paying for a full rescan on every sto= p is
>> something not needed I think.

>I mean, it *could* change, you could do "next" over a functio= n that
>spawns a thread, a background thread (one other than the one you step)<= br> >could spawn a thread, another thread could have exited, etc.

Yes, in the v3 version = I have handle this. GDB resumes all threads (to let the callee execute), using ptid.tid() =3D=3D 0. That path in resume() sets last_resume_step =3D 0step_stop =3D false and the full syn= c runs and any new thread is caught.


>It's unrelated to this patch, but I happen to be looking at aix-thread.= c
>because of it and I must ask if these things are still relevant, given<= br> >the AIX versions and configurations you support nowadays:

The first patch in the coming series addresses these. Thanks for pointing o= ut.

>Ulrich already pointed out that you could have one thread appear and on= e
>disappear, and the count will not change.

Yes, this is something = I did not think. Thanks to both of you. The v3 patch implementation is base= d on single step only.  No thread counts used. 

>So yeah, what about doing "next" over a call that spawns a th= read, or a
>background thread existing while you do a next?

The fix is safe for both scenarios because step_stop=3Dtrue is only set when software single-step breakpoints were inserted for the re= sumed thread which means GDB knows the thread executed exactly one instruct= ion and could not have called pthread_create or pthread_exit. For next over a function call that spawns a thread, GDB resumes all threads (ptid.= tid()=3D=3D0), which explicitly clears last_resume_step=3D0 at line 1087, so step_stop is never true and sync_threadlists() runs in full, picking up the new thread. For a background thread exiting d= uring next, the single-step skips only apply to the internal one-instruction steps of = the stepped thread; as soon as GDB resumes all threads for the next source-= line boundary it clears last_resume_step=3D0, so the following stop calls sync_threadlists() and detects the exit. In both cases sync_threadlists() is always called on any stop where thread population could have changed. T= he optimization only fires for stops that are pure single-step traps of a s= ingle thread. No new thread can be created or destroyed in one instruction,= so skipping the session update on those stops is correct. This is what my thought process is.


>> +/* Number of thread descriptors to fetch per getthrds() call.&nbs= p; The original
>> +   code fetched one at a time, which costs one syscall = per thread.  Fetching
>> +   in batches reduces that to one syscall per GETTHRDS_= BATCH threads.  */

>No need to document what the original code did.  Just keep the fir= st
>sentence.

Sure, corrected the same in second patch of the coming series.


>> +#define GETTHRDS_BATCH 64
>Prefer:
>constexpr int GETTHRDS_BATCH =3D 64;

Done this in v3 version of the patch.

>> +
>>  /* Search through the list of all kernel threads for the thr= ead
>>     that has stopped on a SIGTRAP signal, and = return its TID.
>>     Return 0 if none found.  */
>This predates your patch, but is the comment for the get_signaled_threa= d
>function accurate?  It says it looks for a thread that has stopped= on a
>SIGTRAP signal, but the implementation seems to look for any signal, no= t
>just SIGTRAP.

I have corrected this.<= br>

>> -  while (1)
>> +  while ((count =3D getthrds (pid, thrinf, sizeof (thrinf[0]= ),
>> +           = ;            &n= bsp; &ktid, GETTHRDS_BATCH)) > 0)

>>Prefer declaring the variable in the while statement, and separatin= g the
>>comparison from the assignment.  This should work:

 >> while (int count =3D getthrds (pid, thrinf, sizeof (thrinf[0= ]), &ktid,
  >>                 &nb= sp;          GETTHRDS_BATCH));
  >>       count > 0)

>>     {

>> +      for (i =3D 0; i < count; i++) >> +     if (thrinf[i].ti_cursig)
>> +       return thrinf[i].ti_tid;

>Declare variable `i` in the for loop.

The above two are addre= ssed in v3 version of this patch. Simon, that works with for loop and not w= ith while. 

Have a nice day ahead.&= nbsp;

Thanks and regards,
Aditya.


--_000_LV8PR15MB6488198E4B3AE10E92164289D6BA2LV8PR15MB6488namp_--