From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id EQ7LDByBsmrj1zIAWB0awg (envelope-from ) for ; Tue, 22 Sep 2026 09:22:36 -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=Cd1EkTI5; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 217271E06B; Tue, 22 Sep 2026 09:22:36 -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 46AE41E01F for ; Tue, 22 Sep 2026 09:22:34 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9A7EA4BB1C16 for ; Tue, 22 Sep 2026 13:22:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9A7EA4BB1C16 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=Cd1EkTI5 Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 80F014BA23F3 for ; Tue, 22 Sep 2026 13:22:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 80F014BA23F3 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 80F014BA23F3 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=1790083324; cv=fail; b=vYUKbquQbOQPF0PJOlJ5U7cKH4RF0gpXvaa70OhcHnT9CVRr46lp/GyCrdhtfMFdk3YtfmOOfo0fBnDI92Fi2v3mkIZorDZZ2j+yLZ+2TBHJA3O4XE+i0pcYzohHlnS9EKtVdg5mv0rOxP+UGsPhcOWYozqdmYu27nw1Hurawl4= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1790083324; c=relaxed/simple; bh=VImTJyZHYK/5A/jTL02VY1UgDQxbDWWjmR0fzho7aow=; h=DKIM-Signature:From:To:Date:Message-ID:MIME-Version:Subject; b=pV+B8WykVl0SIyrDJe8ZjPUxCkePLass0E+PdXCw+ttfQNlZ88i7dx/LcUoJimHxNQ+d0ypiG8aANGgBwQZe2bHYUozzQnPquiJcYbbCOEaApNUvEnZx972RlePMoylvjIiLr/OYRdrWbVohFPpbd06qz4zpk7Ql6izqvfBLe4E= 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=Cd1EkTI5 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 80F014BA23F3 Received: from pps.filterd (m0360072.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68MBZtcR344027; Tue, 22 Sep 2026 13:22:02 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=0vuZJZC/rb7XVIrxMNv3ZxmbVmKqKc 7OlYkL+29Ne2I=; b=Cd1EkTI5d5CNh9b608/mVe1EECWJllBPDyqgSHxAohiU9M VsJQ3z5CbubUcygAjSbmkZiiQhtMf6OLdj6a+Z41arK5IeJqAbZ7t/gG2kv4h62O 81QjOVED/Eai9Aoyp73D5B95NFD8fTNrNnYnt+IN/B8SDlrJwi6ejYbS0bbXnGZ1 qI3U+D15nU3fIyxbDCTyAHLecdoioiDaVA/8Pcu/oRhYVzIN7tXIvt+qeZzvk204 fCusKwUJ3CUSH3c6iDAVPHsL+1ikmBnV5DzsUfTZdCmDmB/FcTCSkPlEP5PBaXMr pJfSxsy9Kgwv738qCJoeFRYVRHMujCwXjGRlztFw== Received: from sj2pr03cu001.outbound.protection.outlook.com (mail-westusazon11012044.outbound.protection.outlook.com [52.101.43.44]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gskdv5mn7-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 22 Sep 2026 13:22:01 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Dq7MwYYL4+q2/iSZ2nWwNjSUeyleWqhCZYsCvkIShROsp1Rdurw0xLO2iuH1dQQBcKB3a+N+wtl2UskxnLSgQyWVaFLqRkr2XzS1ZB0VHs8K2xCRp9/YxT46NQO7jC8xDmOuMkPFS4oltd0p4OcRC3/uBMLRpw0UWdBPay6O/JvSK27B5LXtzKf5PFzcCRnbhtas22HO3+tCPkg1J0zEMiJjYcHwGOS7jgLs2eEnsI/2esmCVCattVuhk0MPaOAbJvgSUAiG/+G5xNEhM+7tu4EzAnnt5sVvn53Xc1YtH8PDMlhQ0qS8p5Mt4uFhFBwtht1r4avOXMQtsNOYDlO8Jg== 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=0vuZJZC/rb7XVIrxMNv3ZxmbVmKqKc7OlYkL+29Ne2I=; b=DT/ZPT+9xTpNpVxQy0LkLKocnz9GTMT4PNvl2cHe83ve60SWd0Q2SEfzcHSJEfHMOqxw1WRI1HcTtDkwC8SotRuGmOJvbejEeC4w+2jHZ37bcasPSC/lpCwLsMFhsAsRAFmUBK3bxYtgLCJ2WrTuDv7RUZH9JYCa/+D99gO5tjJ6Xkn6yaMaTa5JQqmHQOLylsPqePVnPp0tWA6MSMLfEPnh/7jb/b3mtKMd7tpH6YVZLAq4jtea65TOqT86Ls0QWvfaLUj9Xs1I2j+XRyYU81+yN1qZ7AoPYTNm8z+tgkvD/6HpwTHOoCY/eakisKSyfg2LRL022Uyd6d7Q7Tt9oA== 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 DSWPR15MB319817.namprd15.prod.outlook.com (2603:10b6:8:3b5::13) by SAWPR15MB7116.namprd15.prod.outlook.com (2603:10b6:806:4e2::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.451.14; Tue, 22 Sep 2026 13:21:57 +0000 Received: from DSWPR15MB319817.namprd15.prod.outlook.com ([fe80::be5:16ae:394:f4c8]) by DSWPR15MB319817.namprd15.prod.outlook.com ([fe80::be5:16ae:394:f4c8%7]) with mapi id 15.21.0451.014; Tue, 22 Sep 2026 13:21:57 +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 v3 3/3][RFC] Speed up next/step while debugging multithreaded programs on AIX. Thread-Index: AQHdRg6H6PLBAAgNnEqhQcqUuBweMbbamPeM Date: Tue, 22 Sep 2026 13:21:57 +0000 Message-ID: References: <20260916114931.17516-3-akamath996@gmail.com> In-Reply-To: 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: DSWPR15MB319817:EE_|SAWPR15MB7116:EE_ x-ms-office365-filtering-correlation-id: 6b9ad180-3ffd-439c-c5a8-08df18ac7a43 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|366016|23010399003|376014|1800799024|38070700021|6133799003|3023799007|10067099003|11063799006|5023799004|4143699003|56012099006|8096899003|18002099003|22082099003; x-microsoft-antispam-message-info: yELrCbeK7zXTApwVlVo3ZyDywA4dFmvLL6B8fAq1DLT1lBZGTmMLUvdhT2rbsoAx7LNv2h0p3orZ4saDLxCrehGqg2qcvlQYHgnW/lioIN5amctbxKS3DmTKCwFJay1icRMOu6sqhJGWvquC05BG9K6REhWjb88UHqtY2gjc+1pj4iOf9qlw0lpGxyibk4bNiVxyAbEUCqs0M50AsS0VfJciDC8sHZ52tt05s2+9kVyFBlUt7EFYEWYH21OnVi6+iep6lO0gIjYLFUBR5DISMao+7S4hzMGFyXIZOXLMShn3mwubM+wBtCZFqmSp4YScdVkYqjxAIWWx9oKv8ULP2cJiOmLPaT2jeLtgNqVCuEhjI3QSFem10h1F7FZwKB4dAHzjt74xK3WehOHxKZjAD9XrbVoSy5geMtv3+V2omi3Z5/3OpRu+RfGOBPxHhgxznvGp5tHl0RQqb7+vrm4kJN4T14JoS8Q7kjCmbu06fv3Bf8XEhKLXp9+5Nu5aXTYTwyk9OSR4BTkkl/dzqMuU/DdCBOBhTILFnsVXTr3Zz237JxSLrGQH46RyKDADZL9F3sX2YiztMvO6UIJbikjTT3nbYDHs2J2H61r015k+YSx6zV2sRLkpmNtO1H04wknf5ds/Q2qFudcho+uS/RbvnY2Kbcpi3IMCzItqa5Y69/tWtr+RJUQMJ2RAbOLgTk325eZQivBNhSixuN7J7B3x0tcIso2uT/GF5AYiXeJUQWM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DSWPR15MB319817.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(23010399003)(376014)(1800799024)(38070700021)(6133799003)(3023799007)(10067099003)(11063799006)(5023799004)(4143699003)(56012099006)(8096899003)(18002099003)(22082099003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?esHQGNbNinrxN/qOsFolMGBd7/PZFmvhKo1BjYawdLtBJur4y0F/O/DD?= =?Windows-1252?Q?nK6wWspBOon5DRaVMoTdOXoGy8szwnImXjU5Ii7qm8xI38GTFXudY5y1?= =?Windows-1252?Q?qRzRSJ5U1DriRNWmYJ6ftXoLmY6dx4jOTe+Ut524uBiBEbDH8+y3FKxg?= =?Windows-1252?Q?lRNgfjlflzifdndgHeIL4pJKojzZHkxmfl3xmqVYrKPUD+arf/onYrNC?= =?Windows-1252?Q?oyjqqgt1sXu2Xi6HmVGOEZaiB0fWPndfIiDEOb3yh8000XqweUmMIGKs?= =?Windows-1252?Q?OtFL+B0ATfs/+D4xMQoZksxh3XPz5napVz6g9lqcXvWRwTsCHHa8w7qQ?= =?Windows-1252?Q?lN7TJpU1qs7rQsyECwxyVl+a8pGCBoOQPjMedPlfyAqxZHEjPoPfkJvs?= =?Windows-1252?Q?ilbOqczRxqUPa8WNneLS3nfYm6RnaV/AQUIC2o489rpbQd1cDg3Qwaks?= =?Windows-1252?Q?htVEw25KjvzBFqD6lN+eS6A72C1y6x3iWS9mCzWJPNw1fQTVGzh5vW9O?= =?Windows-1252?Q?Fx2Ue7jEuC91vxLAL1TNdAliSyoLbew5WLkvSyVH6/yO90TzmdC7AttJ?= =?Windows-1252?Q?j0CyjTeeiq9gaMF4y1o30nSEfc3CbDt5T/Z1DertJz5iv8r5awmK4MWx?= =?Windows-1252?Q?sv8PBbCKi/z+0Y4VR6HsM0vNt30VWLVOC9IVHQmkvjp/+0qipWe3uFYu?= =?Windows-1252?Q?b/bgz7M9ao7EGPCnsXBLjjhqS2TgYQ+pRjp4pjD0Jg3A3b4MRAOukmc8?= =?Windows-1252?Q?fPb21KhiaySg7WYNXxD7UIKog4rcyv4xtq5p4qp2yWVfdjGKYp22udMY?= =?Windows-1252?Q?kDXryX4zJZ4K6FK3v2P4h/UA7Dxh8iCrtnQ9gFbdGWKgWyFsC4MNkRHv?= =?Windows-1252?Q?CHV/L7jiQHFqrOoiK5zxmYuXAyNLeQC2ANB6CBcGXnU90f4iGvLgtxs8?= =?Windows-1252?Q?VpBFz4dqfw6Y5REzXP4ZvFuihJuigTk+xPu36h+8iV/9VOuB9w3APc1Y?= =?Windows-1252?Q?LsxRPYF/uwmqYP6Lg45u2Gf+29UxqnWB/4qDyBqxovBXa2EUHj3DXmbf?= =?Windows-1252?Q?fPhwbLJY0g4Yk1oDVBPEDJbotSJWOu9iTHWJj//UlDtjGpU9oPsdaun1?= =?Windows-1252?Q?tlKLndO6/sTX4w1YClMHPHuNtCxzSi5l67ks/B2f+9I5T+CAPfqWyvk8?= =?Windows-1252?Q?BY4c7ts7/URWhKf1QJeQjqSXWnpE/PQRgkPcLBFIrtdnSp0jXyWE15gS?= =?Windows-1252?Q?i7igm1gJHf0QD120la1GRb2WzTxasy86pF1EfBmOL8FZMHURJgckuEqQ?= =?Windows-1252?Q?ztsGpw9Lf3C6W4RMfNWRv4Yun3xlx0kC0M+GmeuwXWCKh2DgwrsEpn81?= =?Windows-1252?Q?YdqE23VqkAwlw18QgLGuzRuE8P8YBMJX+GNsLZq3qA+nK2scqWc3nugH?= =?Windows-1252?Q?MFMHr6wrd7BJMDRilfgNBLA2tAPQoGmCIhuH7VESs4gRSMAGhaLuc8cq?= =?Windows-1252?Q?ngcHemPjdEeAUfxTe4NGRxnRPThqH/Qx8Lc0rT628TyXD+IHcousuJIT?= =?Windows-1252?Q?zUJimEqhe9or47Tame9y1ufd0WZ2j2J+ULmWGbtoQVqJeM/AG1gOGMPG?= =?Windows-1252?Q?NcGvS9Vgyj5qrTj3VbFDBXQrWGwLM0U3KhTvapny6pUqAAKgxAgUuAm4?= =?Windows-1252?Q?SfK9B0ydbXzSyR3G5mb8nztDiAK0LKvPkrANynUR40VpBOBoQJhonsvj?= =?Windows-1252?Q?7AQGVOgTna8z56DKSxTJjAvZjFJCOHztVgxa18streliRuZYN4gMJ2Kr?= =?Windows-1252?Q?a7ELFUCPH0FT7CCipFqqnWPRIckAvBb/V6LMNzuM9nSG8bplG4zfI1hv?= =?Windows-1252?Q?6idiEBjG293Hjvhep7jCEkB/j6NVpL6WHIs=3D?= Content-Type: multipart/alternative; boundary="_000_DSWPR15MB3198175BF4FE200243EEA9A475D6832DSWPR15MB319817_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: blwJ5hjVVhsLc1ZtEN4iCYQXgspLvHPQ0yAJD4rZaHXihtuaZiIZRMhs8qY85+6PtB+K1qkJdFovhLwF7f9Z0dDj6vf/IU3c2RWjM6xK3/NeeECkOLshSMRXn9DPIjqQ2m3Q+75NuS9ygMkSYMmqoZVCDUYzg4WS16vcTwSy8/bbItGLXkfU5BQpKWKj+j4pUY/zZaDLN5gcHU5ztNupUe4AjZrpkJnGJEzYQWo1iNByOpq6e4m2/DVCDkFIM1yst5Ld7daZZBUteK7Q8IYMMZ4l0aMndCpG5h+TzjioG4cLfDpT7sw1w0tISbIhQilcq9Cay+fBWMssI1rip4ANOg== X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DSWPR15MB319817.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b9ad180-3ffd-439c-c5a8-08df18ac7a43 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2026 13:21:57.4447 (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: dMuovfBT5HTIt01IPmOLsP0iBfzOj3Ll/D0gdKJAVngGcqkRl7Pp6OmnArj3JW1oLunDD05jeR+1vyK/SuHWbA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SAWPR15MB7116 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-ORIG-GUID: wnEeNmNVSFs3dz3cTEBPiY11DDT6i_S5 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTIyMDE5MCBTYWx0ZWRfXwLubCbxAu2dH dr5yjvIcZuz36T7136BGJpfc7P/yjB3pYi44h+NVQni0BL9TcEaeqoOu+s5V+vih1WCXEQMQtYG QqUy9X0vSFMqpFvkuGmhmNCMfLN0ZQU= X-Authority-Analysis: v=2.4 cv=FLiOVOos c=1 sm=1 tr=0 ts=6ab280f9 cx=c_pps a=JJOFz727VvkGy7wKLfv01w==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=RzCfie-kr_QcCd8fBx8p:22 a=R8-V3vmUd3EbjTvmj90A:9 a=pILNOxqGKmIA:10 a=zjsWyc2oiCF5BFPC1dEA:9 a=AWu9AQs5l9Krl89W:21 a=_W_S_7VecoQA:10 X-Proofpoint-GUID: ycGPJuJtmz5e5rXGa2BG7222o651c4zI X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTIyMDE5MCBTYWx0ZWRfX1FVox716O69H 061HJsmHOZHyvPoO7wVN0DtKMnHOz+s2IpeEtZiOtzgCkygTw9PNKaGM4HRp9iWsvudg6wFOm7g 1F5Ute6Juw8Xa1kDreTfWWuXRzX4aB+hGYsQt2aX08fjE4xF56A4lFRu6GxSPQZchZ+RwgV/we5 QGaZC9oIaaXN9iqE2H8iVPsqYxVlKNBK5G5KcWz4V9GCrvYkmRFF4UEUvlrM0Ht97Qs12Dt3Ghy nSnYNUg5mr7RiRNaGCrmq0lYnAk9jQVmvuCGiiOxHadflG/P7arH1gcBwyaJi5eERBOMi1xzLOS 8Fn3gzL5j619yTlIz+EcJvJy55ToyG6L4CszS2u1oV7on5BBQ1lXnjGaz4wiNkKoyUAe6CAP8ex NNwkBMuyP9ZBcSyx9owO75+ctJF0HFdPwiolWJpekXchI6NA361S+sQWwIIOfegpMV52thcwnC6 hZi2j/pMNEoOGPB4n8g== Subject: RE: [PATCH v3 3/3][RFC] 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-22_01,2026-09-21_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 impostorscore=0 phishscore=0 spamscore=0 clxscore=1015 suspectscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609220190 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_DSWPR15MB3198175BF4FE200243EEA9A475D6832DSWPR15MB319817_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Simon, Ulrich and community members, >Again, I am not sure that's true. There is certainly one single >instruction (possibly a syscall) inside pthread_create that commits the >thread creation, after which the new thread will be visible. If you >single-step that instruction, you'll have one more thread after stepping >than you had before. >And with "set scheduler-locking off", threads other than the one being >stepped run freely during the step. One of those threads could exit >during your instruction single step, so you'd miss that. >If you know that new threads can only appear during a syscall >instruction (I have no idea, just speculating), then you could perhaps >check what is the instruction about to be stepped. If it's not a >syscall instruction, and if the scheduler-locking setting is "on=94 or >"step" (nothing else than this thread will run during the step), then >perhaps it would be safe to skip the thread update. But you'd have to >check how it really works under the hood. So, from the scoped_time_it instrumentation instrumentation pthdb_pthread, = sync_threadlists, pd_update costs 1.2 seconds roughly in my LPAR. get_signa= led_thread, pthdb_pthread_state, pthdb_pthread_tid, pthdb_pthread_ptid, pth= db_session_update are all free. They hardly cost anything. The very first pthdb_pthread(PTHDB_LIST_FIRST) call inside sync_threadlists= costs ~1 second per stop regardless of thread count (same cost with 3 thre= ads as with 20). Everything else is essentially free. That one call is what= libpthdebug uses to start enumerating threads, what I mean is it walks all= the pthread internal data structures in the inferior process. Skipping syn= c_threadlists entirely on step stops eliminates that cost completely, givin= g the 4.2X speedup. As you noted, stepping over the instruction that commits a pthread_create (= or observing another thread exit when scheduler-locking off is in effect) c= ould cause the thread state to change while the step is in progress. So ski= pping the update unconditionally for every software single-step would not b= e correct. However, as you pointed out, doing so unconditionally is not correct. If a = step executes the instruction that makes a newly created thread visible, or= if another thread exits while scheduler-locking off is in effect, then the= thread list can legitimately change during the step. In those cases, skipp= ing the update would cause GDB to miss thread creation and/or thread termin= ation events. I have not yet found a reliable way to avoid this. Now it app= ears that the real bottleneck is the cost of pthdb_pthread(PTHDB_LIST_FIRST= ) itself rather than any of the surrounding GDB logic. Given that, I will d= iscuss this with the AIX maintainers to understand better opportunities for= improvement. Thanks again for the review and for highlighting the correctn= ess concerns. Have a nice day ahead. Thanks and regards, Aditya. --_000_DSWPR15MB3198175BF4FE200243EEA9A475D6832DSWPR15MB319817_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Simon, Ulrich and community member= s,


>Again, I am not sure that's true.=   There is certainly one single
>instruction (possibly a syscall) = inside pthread_create that commits the
>thread creation, after which the = new thread will be visible.  If you
>single-step that instruction, you= 'll have one more thread after stepping
>than you had before.

>And with "set scheduler-lock= ing off", threads other than the one being
>stepped run freely during the ste= p.  One of those threads could exit
>during your instruction single st= ep, so you'd miss that.

>If you know that new threads can = only appear during a syscall
>instruction (I have no idea, just= speculating), then you could perhaps
>check what is the instruction abo= ut to be stepped.  If it's not a
>syscall instruction, and if the scheduler-locking setting is "on= =94 or
>"step" (nothing else th= an this thread will run during the step), then
>perhaps it would be safe to skip = the thread update.  But you'd have to
>check how it really works under t= he hood.


So, from the scoped_ti= me_it instrumentation i= nstrumentation pthdb_pthread, sync_thre= adlists, pd_update costs 1.2 seconds roughly in my LPAR. get_si= gnaled_thread, pthdb_pthread_state, pthdb_pthread_tid, pthdb_pthread_ptid, = pthdb_session_update are all free. They hardly cost anything. 

The very first pthd= b_pthread(PTHDB_LIST_FIRST) call inside sync_threadlists costs ~1 second per stop regardless of thread count (same cost with 3 thre= ads as with 20). Everything else is essentially free. That one call is what= libpthdebug uses to start enumerating threads, what I mean is it walks all= the pthread internal data structures in the inferior process. Skipping sync_threadlists entirely on step stops eliminates that cost completely, giving the 4.2X sp= eedup.

As you noted, stepping over the instruction th= at commits a pthread_create (or observing another thread exit when scheduler-locking off is in effect) could cause the thread state to change while the step is in = progress. So skipping the update unconditionally for every software single-= step would not be correct.

However, as you pointed out, doing so uncondit= ionally is not correct. If a step executes the instruction that makes a new= ly created thread visible, or if another thread exits while is in effect, then the thread list can legitimately change during the step= . In those cases, skipping the update would cause GDB to miss thread creati= on and/or thread termination events. I have not yet found a reliable way to= avoid this. Now it appears that the real bottleneck is the cost of pthdb_pthread(PTHDB_LIST_FIRST) itself rather than any of the surrounding GDB logic. Given that, I will di= scuss this with the AIX maintainers to understand better opportunities for = improvement. Thanks again for the review and for highlighting the correctne= ss concerns.

Have a nice day ahead.

Thanks and regards, 

Aditya.




--_000_DSWPR15MB3198175BF4FE200243EEA9A475D6832DSWPR15MB319817_--