From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ccTIB1mDomrHbzwAWB0awg (envelope-from ) for ; Thu, 10 Sep 2026 06:15:53 -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=NQNdcBw9; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 1B5E01E09E; Thu, 10 Sep 2026 06:15:53 -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 4AE111E091 for ; Thu, 10 Sep 2026 06:15:52 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 632E34BA2E3C for ; Thu, 10 Sep 2026 10:15:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 632E34BA2E3C 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=NQNdcBw9 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 2E3724BA2E17 for ; Thu, 10 Sep 2026 10:15:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E3724BA2E17 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 2E3724BA2E17 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=148.163.156.1 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1789035314; cv=pass; b=mhMXFMvQ8WK9yxLNhRl8SLEz1JtcC+tjTxnh+RNRbIjLolxAzwlvIWNuovBwY9DSz6DlzS6eMZ6Bxdk31u7kwteflrju9BuxU69NmAkbEcvei/mXiATO7CsYA0k5R/hYZonMT1dUbYLa92GmfOlK64STQvciDJ5ezptPr38Hl1Y= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1789035314; c=relaxed/simple; bh=dyoYpboJrNqJyR25Vpq1mB9j9Br+67C1lU7kJdDObr0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=O/mF8gjQmABg88YDRiOPvD/eoAQUGEaP+FeE7JUM7jjspCNecOoW5YQKwQxJasx0mgaIFWyN8SHy12/GfXCkMsH688TWXbL/4nVCZKKy83t85M4g/GmB6V52XNths7nCXv/kMmU1sZ6mXD5QAS8Pg/pxaQ8Ze2Kv7Z+ShZIrFI0= 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=NQNdcBw9 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E3724BA2E17 Received: from pps.filterd (m0360083.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 68A91b8S2470330; Thu, 10 Sep 2026 10:15:12 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=FOuoyIO7PXPF4lgG1XbQoTYFGEJDk3 WXo3q8kHk1JOI=; b=NQNdcBw9u/NpkEEU+9hliDQlYksWVAxwiAbkdRcg0Q2qhD bch+yhhHeYb4tNP+2uSIHDavcIxRGhsG/XjWvBTKjbZBsvLRe8JCwvBq+oJ/HyoR ENfGWVGQ/XFShA7PhexUGfrOCi/l0kKtyMh77RdKofr+TzSPJRydDiIHdJUHfaK+ 0bd4MaolVfRBFSIWtN2XZ6mi/N4vV11NoYF5P9g2l8Ipfiif4q8mpA+RXiG52wFn eHupbCbZXDXTLbnUXH7gbZ+GuUdpRk7RiuXm/7rtxR+Wn2ydla5CJsmHN+4gwm87 MDG9kHMO9hm7fnfg8dSjA9z3GGV4wFeKxZIBEnQA== Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azon11011037.outbound.protection.outlook.com [52.101.57.37]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4gkd8qktyj-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 10 Sep 2026 10:15:12 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=XQ9Ir6/OOrjUOhfYy+zMZKFKhEMtsmkhgZp+iokLo2//GE5d4J5J7hzOo5UlqXmBRxP7nekwvwMY2DNKcZAvLN9tbWhSyMpPpvHLqUk7VuiMSk67fX6bXVejQhkgGwWz6T4O53p5fEhxhCPjeiN49RuSglUQrUQZdzcpNWy6PE5vTE0goSpe4imRgJdydcyWZmeeUT20u548ikSqxIiBmQEB9xhKcCXAIzDGdhwyG26kztXmX6DlTjGy9smb5PiayxCSAgxoJO5d1l1akBnl1PGG6bkK0p0pOOvu5WGKVGtXSO7JumsUAhWa628M9I47y0jwkF3g5Qnvg/+5dV6bQg== 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=FOuoyIO7PXPF4lgG1XbQoTYFGEJDk3WXo3q8kHk1JOI=; b=YNBKrjKIn59ciqPw0TOlHOnmrXKL2CNanxFxdmvaDzcR3/Vf3n0YHHnZll6jgspBotlh31xEAj3l4AMtlFJ0dI36rtICkh09hyJ0RJORol8066ZsbpGrFpCF8jVpwZbpM57jB14gk++tdGfZwkU1L2rnu5hEe4BCjVur6ynNmHL/vv6i35SW73dnCKVy7F5d2ESRYAIZd//enPURrjQb6OcICArr/1e8OyMsPfmbkD48AdGTFHpndHSR3c5GQnZkDkxc2NX/369vALZI1ixlRNxMxSy2PzhsBJBV+1OQDdBCXMzsTz+HQx0kgEusYyrdg7Kw+BepHuiEh5og5DMCmA== 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 LV8PR15MB6488.namprd15.prod.outlook.com (2603:10b6:408:1f4::13) by MW3PR15MB3882.namprd15.prod.outlook.com (2603:10b6:303:49::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.9; Thu, 10 Sep 2026 10:15:09 +0000 Received: from LV8PR15MB6488.namprd15.prod.outlook.com ([fe80::cc4d:8604:c04f:2a40]) by LV8PR15MB6488.namprd15.prod.outlook.com ([fe80::cc4d:8604:c04f:2a40%4]) with mapi id 15.21.0406.007; Thu, 10 Sep 2026 10:15:08 +0000 From: Aditya Kamath To: Abhay Kandpal , Aditya Vidyadhar Kamath , Ulrich Weigand , "simon.marchi@polymtl.ca" , "tom@tromey.com" CC: "gdb-patches@sourceware.org" , SANGAMESH MALLAYYA Subject: Re: [PATCH v1][RFC] Speed up next/step while debugging multithreaded programs on AIX. Thread-Topic: [PATCH v1][RFC] Speed up next/step while debugging multithreaded programs on AIX. Thread-Index: AQHdQITqiPaq9eP3PEy8H811rHYHcbbHlJp4 Date: Thu, 10 Sep 2026 10:15:08 +0000 Message-ID: References: <20260909054306.73173-2-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: LV8PR15MB6488:EE_|MW3PR15MB3882:EE_ x-ms-office365-filtering-correlation-id: 4c0e6c0f-61bd-4250-3db1-08df0f246442 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|1800799024|23010399003|366016|38070700021|3023799007|10067099003|4143699003|11063799006|56012099006|8096899003|22082099003|18002099003; x-microsoft-antispam-message-info: bR56sWsTmrTpOp6t3UDroNY8SubiGVl0KwBsnSeuimMSBtIdM/hG2ronkPltqhA2THZteO24d7L0Sgolz80mHFcJ6tSFY8msI1bK/aIXaUe2hUGFpuw12znNGwXMvlDQ86yhswBcXLBnDrvVmVRrJF0t+GbhTe9NrSE/ziGFypd66T8ji/nhU4Y2DzzWtonEyLtKj4Pza8V1fOxIMiVv+KaLVn9+0fFZRcou+T87vmyjLYuRiuulQiQfKGT/PyKq8keuwsTZhSHKZ3wsatXEUfjQEMM1pT2GScl7fCNMqGQqZyv/NAeVMH+bzoKFsHFtQ4XD1f0K4q4vOxkGFpgWbDwGn7Uysao5c5cWbsypr1U72XTX2E70Kw7jQ1U744ywI1a9nc8q796sOxr5eBUcWZ3m4EVA1FFDI4pYc2FOzbpgM6wfZ9gp4GKgQSVaCaSekjUgKBKDme1WMVH3IsZkNamk7P2Z6DQKGyFfjKi5kc3x4H+nYEXbYgiNxMixYb+6H6/tSWwPEUcVp2v+9zD7xFwZ4K4r94YdWmDh71ZUMsganbK8T8to3VVunz2sCEfswiGT8RvH37w3/ah56647ro3vA5V6xNd7VRBqIEtl60ndPNhzU+lOYzEMYQUg0aW1EvmSa1h9chslZWP+zbJHTGncKBbOd7CdCm0nsby2dXKm30lZRYTDTnbABsU0LZ8CNvyL2p7QAmUW+Zh3kHN1ICI6GHmasBkxFNIja4/fo6A= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LV8PR15MB6488.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(376014)(1800799024)(23010399003)(366016)(38070700021)(3023799007)(10067099003)(4143699003)(11063799006)(56012099006)(8096899003)(22082099003)(18002099003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?pq6ij98z2J9hyKSBk4awYS3xi6SXQt5tD/QUObdI2r68XXcaLxbQMaRK?= =?Windows-1252?Q?uPno6S1rmyBuHGGqyPKjL194rzK2gc2I8VS5DXLao0G3I1UzG/RyJjlD?= =?Windows-1252?Q?GRsoJincP6D4asvGUFJF6Jomg5sfURMTyUH1xlCgUpzcHtj/zGgT0G3J?= =?Windows-1252?Q?zu/iY20iKSVto1Qk+L4N8C+RHyk6pl9O5N4RVU56ADOrnHaXxRt0BIsy?= =?Windows-1252?Q?Q1FSaylRgCIH7s94nbpu0VQ1vmNmmaGU/MpN4RBXFFEQb5wzd5ODvAS4?= =?Windows-1252?Q?ReMDgWbbm4x8vQRp5XnHM6YIZ14C6CRMZm9IKpvOX8Acg0rfGbep8+Qv?= =?Windows-1252?Q?KANB1fH2ic+LZIeOGJxT1R7hMHLCDHVzd1C1EiZ9kuL9g7qeiUyQkhnf?= =?Windows-1252?Q?//wn7Mu0Q8dqhevF/7KYpp2WGAvO14JVzh7wbkELIAqOdEWKa6FV90gY?= =?Windows-1252?Q?Ziz+UCfn8zPAuIJLTfd2P2riH/YJORDYHlayHE1ldPhWPENqkL//mkM7?= =?Windows-1252?Q?P2i/yt8XDiNF7CJylCuULYWrHyHJ6uxVf5TGuHl53bZ8/IAkd42kxAS/?= =?Windows-1252?Q?6uaViy8c9VdHDmtaFmn6vdkLxWH3qJXgnz4HdSv4XNYB8kCoMISvIbJr?= =?Windows-1252?Q?BJ3PX6XUn0/eC7/4d+CXKqHgxB1T9GZQuSO4J5MSi6PDda1pbw7VTR+2?= =?Windows-1252?Q?3N0QhoRYzhp2drzoSYuVdfaOf04qHTlHi9t3xLCPA26idmUx5NNsSza6?= =?Windows-1252?Q?sKUUMZlEp1+PwZ2zsV9GyWZQ/fBPHsEFtuPb74Cvv1Bi037Fo9gUhhgI?= =?Windows-1252?Q?LJVyfg0MUC1LMCejVLerUD8wAYu+1dVokotss9MIYG8n8gduSVwoOS+J?= =?Windows-1252?Q?t2V8kobEkj2l10DGoPLZYWSps8vRyEB3mBa1yFXEzusTOjYq19nl8nYq?= =?Windows-1252?Q?D9kFu8+3kcwL+lD1dXZFSwsYr1WO1XbmH8lyUjGaLb6xjwBati9srSlt?= =?Windows-1252?Q?xhY4Oe3YmvaaD8IFhjlgoh00yoTlvjyXSpZ0HS6P8PU0BOb17MjDIcjK?= =?Windows-1252?Q?2D0M7+omjOQB9O8jzWmtYsisbIBVLNG0D5y1Wu1uBbvMV0K42aGqkWES?= =?Windows-1252?Q?jJ7iyo5XxpBU34O0B4LM36IFCbYOWlqegCX1H5KMwGR3XvfpFSp83bPT?= =?Windows-1252?Q?iqJZHhKjvIg3PE1EOObcazVenIBl+ivUnSX8nYz1DB873B1y4ZjhefVd?= =?Windows-1252?Q?w9QRNNsBApDHHQEFlWiPsdFisIDLllAyzPGkGKUH8NrIdSuu70ZLIkxi?= =?Windows-1252?Q?lBDeqUD0fymEOPl99T5JHU5bDjK22orqD46fea61Cw2DKhuq9A0Dgj4d?= =?Windows-1252?Q?5FlkWxB/sKgX8CKr5wOQ/jj9jynIuDSwayzV66dcHf2xBn31hY/6C9wy?= =?Windows-1252?Q?ViVRN/N+7Skd5pwKHbISCjEoJQcsnzVIhw3yerMFUxm14p6LLcFjgx57?= =?Windows-1252?Q?VNpMcgbidK9nNhTxSYQ2ChhTmeiYFT2rFJgax02iWj+4kHVRLCnkVtz7?= =?Windows-1252?Q?6qvp+izALOa9BGYvnC10911VocIJDTa4CayUC/t4Ku5KN5vwLuZIHgUG?= =?Windows-1252?Q?S6kusRH0Of0zCG0DlzTcWyf0mcoI4VCu1AzfJCepSqyv1JxnMsa/BhOl?= =?Windows-1252?Q?cEeTrZS5tHqlb81vmyMLP0EVRNIEadF6dMwvl1dY+P8XOmeO3s6nGl0D?= =?Windows-1252?Q?xtT/iCS19AkJGZmxSlUjrT+xb+RL/bPql2CJGe1neb06TfZ8dnLGBC4N?= =?Windows-1252?Q?iAsmmdXDjFMiZkWuCvzJeUKn6jTdSSXnC0Mk4WFxoOeSZDbnEQdfhpQX?= =?Windows-1252?Q?yusyXXdGQnViOXuA/FF3kTLoHXB8ZYlHVF0=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR15MB64880A03BF7C3E96F79B4013D6BF2LV8PR15MB6488namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: RCO0AQZBSeLBvgIojxRppHuwmqCv/445yBTNnvbhfKQD0JKw+QgANgutJsdLyhJzDTfY49lVaU+qmgpNvdy5+i6vW65pTvbm6ziUof3dMrFQS1E/qPxD6fBfyXMWh8NhGOloP3E0KGDdmS7ORptuojtyxJHgjIBOWpCLMm6YT8MJexiHn9xCc3/LmghdP9JWNUBP7xVnIICN7KmUOOu62Tg090DgE9n822ea7FcjB8PO9YTw/OIvNVFvAzMSqcHtRCnKZKmBdWxxPlVqvM6OxDwa1iZ/FSEoEUKT/GuEvckspTSTgDVj1pOgDooGZISbnNpobGtVZwS1d/2hmopDSA== X-OriginatorOrg: ibm.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LV8PR15MB6488.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c0e6c0f-61bd-4250-3db1-08df0f246442 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2026 10:15:08.5082 (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: FPcZRv0ghCaT6J0bPFUBKUDHAe5NnUqnkWUKHegsF66rIP6giCnPOSbk8g9jhulAWTQlnfUPm5GAU92/TKv65w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR15MB3882 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=SpUFe/O0 c=1 sm=1 tr=0 ts=6aa28330 cx=c_pps a=S+V0rrE8P+iIDgN9m6arSg==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=iQ6ETzBq9ecOQQE5vZCe:22 a=fekw7oCgUY_chynYpdsA:9 a=pILNOxqGKmIA:10 a=lh7ITcm9j4Otx7xB-kYA:9 a=bvyLbSgixyuTjbIp:21 a=_W_S_7VecoQA:10 X-Proofpoint-ORIG-GUID: Ou9ka8jRhzh0VeoTV-It9Tjgq437Qcuv X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTEwMDExNSBTYWx0ZWRfX8j1J4udZ/gs8 W14f1ihWnQzwFw5QV+XOuxcqm7c660QhXoVcp29bGPtQtGDvTrhjBcS5K/1vLbDPFmUh1KzCQu8 lZjdKeEEpRWAFgus2FrjcBFWpJzug5vEspprGdeU0FvkZzRyxpfytseaG706DKx4IhXmlrddr5S D72HvdBQP4ZuOhHPi7t1qV8Q1IjG+VaG4XnCaKTrkFCjW1ubJ1cknYsxgLCnvipcrtgzxnMpQGO 6vlVZ9LscScJrof6ekwnuwu2AUFVtNvISyL+ZqthLqM6cUHybTP5hhL7XOWvKALCSRYl/2tilXD pJ3a0VdbPvxtzuLM4X2RW6mgkKmj9lp9b6jKfSI9XPEwdXKhLxITbxRbls7SVEGLvh1Xx87jpqm VLClLCODeIKvIVKTBmKtzKkAfj6xWd9WqplgBEkZQVoirEc8GdS+hZXQugmrTUWYiwM7nQ4DJUM vp6b0TtWToSG5LkJglw== X-Proofpoint-Spam-Info: AW1haW4tMjYwOTEwMDExNSBTYWx0ZWRfX8dWMc5IDYsv+ RJ6ck5S+iOmXFu7rW9YsZImipwfPGewgBXINLw5w0lWWpjXtirgQsWDH2/gvS7Vm+zokRY8magc X331jd9muWuBL0e3CXY+5W2hCdm7MGM= X-Proofpoint-GUID: wxln5Fv3IWCOotpGUiO4vfw2Uj0EtCkS 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-10_03,2026-09-09_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 clxscore=1015 phishscore=0 malwarescore=0 impostorscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2609040000 definitions=main-2609100115 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_LV8PR15MB64880A03BF7C3E96F79B4013D6BF2LV8PR15MB6488namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Abhay and community members, Thank you very much for the feedback. Please see my comments below to your = concerns and I am sending v2 of this patch after this soon. >Doesn't a breakpoint stop also arrive as >TARGET_WAITKIND_STOPPED with GDB= _SIGNAL_TRAP? >get_signaled_thread() already looks for the thread stopped >on SIGTRAP to = find the >current thread, and that has to work at breakpoint stops >too, so I would = expect >a breakpoint hit to look the same as a single-step here. >If so, breakpoint stops also get step_stop =3D true and skip >the sync >The last_thread_count < 0 check only covers the first stop >after pd_activ= ate(). After that first sync, >last_thread_count is >=3D 0 for the rest of the ses= sion and >need_sync becomes just !step_stop. So from the second stop >onwards a breakpoint hit skips the sync, and any threads >created since the previou= s stop are missed. You are right here. A user breakpoint hit, a software single-step completio= n, and the thread-creation stub breakpoint all arrive with exactly the same= WAITKIND_STOPPED + GDB_SIGNAL_TRAP. The v1 version of this patch couldn't = tell them apart, so step_stop was true for breakpoint hits too, and the syn= c was wrongly skipped. I checked this. I did not think in this angle and ju= st thought about speeding up. Thanks for pointing it out. Yeah the benchmar= k will not point this out. >resume() is already told whether GDB asked for a single >step, and it alre= ady >has the aix_thread_variables pointer in hand. Could you >save the flag th= ere >and use it here instead of inferring it from the signal? >/* aix_thread_target::resume (), after the existing >data =3D get_thread_data_helper_for_ptid (ptid); */ >data->last_resume_step =3D step; >/* in wait () */ >bool step_stop =3D (data->last_resume_step >&& status->kind () =3D=3D TARGET_WAITKIND_STOPPED >&& status->sig () =3D=3D GDB_SIGNAL_TRAP); >That would also handle "next" over a function call, where GDB puts a tempo= rary >breakpoint at the return address and continues rather than single-stepping >through the callee. resume() is called with step =3D 0 in that case, so t= he >stop would correctly get a full sync even though the user typed "next=94. I like this idea but while implementing came across something else. On AIX = rs6000_software_single_step() is registered as the architecture's next-PC p= rovider. infrun.c's maybe_software_singlestep() calls it, which inserts bre= akpoints at the next instruction(s) and returns hw_step =3D false, so do_ta= rget_resume() always passes step=3D0. Saving that would have made last_resu= me_step always 0, killing the optimisation entirely. In the debug log I saw every do_target_resume call showed step=3D0, even fo= r next. The right signal is whether software single-step breakpoints were inserted = for the current thread at the time of the resume. That is what thread_has_s= ingle_step_breakpoints_set() reports, and it is set when and only when GDB = is software-single-stepping through source lines. So in resume() in v2 version of this patch you will see: struct thread_info *tp =3D inferior_thread (); data->last_resume_step =3D thread_has_single_step_breakpoints_set (tp); This is 1 when GDB inserted single-step breakpoints which is a next/step re= sume, and 0 for any free continue or temporary-breakpoint resume. The wait(= ) side then checks both last_resume_step and GDB_SIGNAL_TRAP =97 both must = be true for the sync skip to apply. Let me know your thoughts in the next version of this patch. Have a nice day ahead. Thank you and regards, Aditya. --_000_LV8PR15MB64880A03BF7C3E96F79B4013D6BF2LV8PR15MB6488namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Abhay and community members,

Thank you very much =
for the feedback. Please see my comments below to your concerns and I am se=
nding v2 of this patch after this soon.

>Doesn't a breakpoint stop al=
so arrive as >TARGET_WAITKIND_STOPPED with GDB_SIGNAL_TRAP?=0A=
>get_signaled_thread() already looks for the thread stopped >on SIGTR=
AP to find the=0A=
>current thread, and that has to work at breakpoint stops >too, so I =
would expect =0A=
>a breakpoint hit to look the same as a single-step here.
>If so, breakpoint stops also get step_stop =3D tru=
e and skip >the sync
>The last_thread_count < 0 =
check only covers the first stop >after pd_activate().=0A=
After that first sync, >last_thread_count is >=3D 0 for the rest of t=
he session =0A=
and >need_sync becomes just !step_stop.  So from the second stop >onw=
ards =0A=
a breakpoint hit skips the sync, and any threads >created since the prev=
ious=0A=
stop are missed.
You are right here. A user breakpoint hit, a software single-step completion, =
and the thread-creation stub breakpoint all arrive with exactly the same WAITKIND_STOPPED + GDB_SIGNAL_TRAP. The v1 ver=
sion of this patchstep_stop was =
true for breakpoint hits too, and the sync was wron=
gly skipped. I checked this. I did not think in this angle and just =
thought about speeding up. Thanks for pointing it out. Yeah the b=
enchmark will not point this out. 
>resume() is already told whether GDB asked for a s=
ingle >step, and it already=0A=
>has the aix_thread_variables pointer in hand.  Could you >save the f=
lag there=0A=
>and use it here instead of inferring it from the signal?
>/* aix_thread_target::resume (), after the existin=
g=0A=
>data =3D get_thread_data_helper_for_ptid (ptid); */=0A=
>data->last_resume_step =3D step;
>/* in wait () */=0A=
>bool step_stop =3D (data->last_resume_step =0A=
>&& status->kind () =3D=3D TARGET_WAITKIND_STOPPED=0A=
>&& status->sig () =3D=3D GDB_SIGNAL_TRAP);
>That would also handle "next" over a fun=
ction call, where GDB puts a temporary=0A=
>breakpoint at the return address and continues rather than single-stepp=
ing=0A=
>through the callee.  resume() is called with step =3D 0 in that case, s=
o the=0A=
>stop would correctly get a full sync even though the user typed "n=
ext=94.=0A=


I like this idea but while implementing came acro=
ss something else. On AIX rs6000=
_software_single_step()=
 is registered as the architecture's next-PC provider. infrun.c's maybe_software_singl=
estep() calls it, which=
 inserts breakpoints at the next instruction(s) and returns <=
code style=3D"font-family: Aptos, Arial, Helvetica, sans-serif;">hw_step =
=3D false, so do_t=
arget_resume() always p=
asses step=3D0. Sa=
ving that would have made last_resume_step always 0, killing the optimisation entirely.

In the debu=
g log I saw every do_target_res=
ume call showed =
st=
ep=3D0, even for n=
ext.

The right signal is whether software single-step breakpoints were insert=
ed for the current thread at the time of the resume. That is what thread_has_single_=
step_breakpoints_set() reports, and it is set when and only when GDB=
 is software-single-stepping through source lines. 

So in resume() in v2 version of this=
 patch you will see:

struct thread_info *tp =3D inferior_thread ();=0A=
data->last_resume_step =3D thread_has_single_step_breakpoints_set (tp);<=
/span>

This is <=
code style=3D"font-family: Aptos, Arial, Helvetica, sans-serif;">1 when GDB inserted single-step breakpoint=
s which is a next/step resume, and 0 for any free continue or temporary-breakpoint resume. The wait() side then checks both last_resume_step and GDB_SIGNAL_TRAP =97 both must be true for the sync skip to apply.
Let me know your thoughts in the next version of this patch.
Have a nice d=
ay ahead.
Thank you and regards,
Aditya.


--_000_LV8PR15MB64880A03BF7C3E96F79B4013D6BF2LV8PR15MB6488namp_--