From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ZxtAB0MOoGovCTcAWB0awg (envelope-from ) for ; Tue, 08 Sep 2026 09:31:47 -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=bcEo1T+b; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id C3BCE1E09E; Tue, 08 Sep 2026 09:31:46 -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=unavailable 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 3B1A21E09B for ; Tue, 08 Sep 2026 09:31:45 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 7FCA64B9DB66 for ; Tue, 8 Sep 2026 13:31:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7FCA64B9DB66 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=bcEo1T+b Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id B0B934BA2E23 for ; Tue, 8 Sep 2026 13:31:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B0B934BA2E23 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 B0B934BA2E23 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=148.163.158.5 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1788874273; cv=pass; b=UgNJSFzBecMyxWyBlqiryOaSIuaiM68b+nUF/jY69FzW6mhPtLD1UdZB9a0JlA7nsnmdwL3B+hV15/2US13yA7B0cR551JUY3S/h9wHP16XAfChOlepuyw2xtJ81d/vebi0T4cTEV2OUobiMyyLW/D+iK0+PKokYq5CF3+F1VVY= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1788874273; c=relaxed/simple; bh=d+j+19nZfDCKl3jc3SxObZyGlEiNqOxC2Wrywr35Kpg=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=hjt4TvtEVl9PHuieZIFwU9A+1MXKcMmq5/D+JmeFs9CIf/LLDDP0QAZmbn610E31UyqyDr9OoTia8Bd4KLQn07/22BeTfPpPqkGaKkX/mlJAvnaXqOWsMS19EtuNPK4RcYOgEUlhWYgECQ71McEpcT68/NSsPASaRByPWggN9zk= 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=bcEo1T+b DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B0B934BA2E23 Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 688D1gIN830063; Tue, 8 Sep 2026 13:31: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=IMiJiigEMqA6MTylEc9arUCJVeX5Th cfZiiGxLGMGT0=; b=bcEo1T+bbV7Vv4sy4Z9StXu34HC3Ji8sbUKZCcn92Ggdzc 3Gc5Szdn0ka7On8OIBdbIUGRaBNZ185P62LoNMxJ5ssz+B6BpOmvk/Ah2GOKWQ4U VOBbJap1l1Gnyj3J39VZ49wXQIpEyJoOiLSkrU9B+nDCQuj0ydRqlVfjST2J/mWB 4FmVlg9Tc7PmcLzeG16DszpHaWPsdOTrOov3f7pLKBVqgRRXBUJPMvvZOhQdkg4P vnw8KPjc5hSYzlKeJ1ocp20bHRvMOsVx3OSdtFuA+7vQxHO7IBEG5TToRRINWlEU s5gbFmtwTtPA+DahhqJJr4gUOgE1PAeuRJGLdw/Q== Received: from bn8pr05cu002.outbound.protection.outlook.com (mail-eastus2azon11011039.outbound.protection.outlook.com [52.101.57.39]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4ggbj86xfu-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 08 Sep 2026 13:31:11 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=YRgCQgW1ewYt8iHgEhhimAgNbO5xY+nQUhQ/vdtj/V4InR2ncljaHhi6n1PMx0DeMV53TxXx8VbLIwzoKVi0xpLT7NWRjd/Re0w0FMEYAmzxu70hzOBDZCJUV+ybPB/viKl02GI20tX3n1sdmxYEropL8+pfJTztpmXcs5QGT1qNP51oEj7YXSgHgz4bdlc6J8C7d6+Ak73wtn3kinqucJwA8GW/tzx/8Ax1Ax3ZLKHREgNddVQFqxveAUca6CmmSftff6A83Iwwt9SK3ufMfF1acXqGjLK7qLoTW5i5+9f80vFb8VvCEss3sPd+1U1MfkGiLf79crIULgrWSRL7/g== 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=IMiJiigEMqA6MTylEc9arUCJVeX5ThcfZiiGxLGMGT0=; b=jW5aHh5NaLkSWqS8u1IPRcklHJEf+UXyDHDnTrhkvKNgYxSrV8Vhj43wNBj3ViZwEjngdHjMzgLMN8Dq5N+Vec9I54Tf/JkctflNfRj9BjADXl7WsJi853H7QcrMxeEnoVNYdoMxDM34fSPeane6LQYbdyADb1rmO0r4uzCx9g+mps9fVt/hEOeihHDEYwMz6z3VD0gbMYQv1jQPxy+tl1KdOm5lcAJzFXh/Tk5nGa2QneT7u3zV9esYh/BH6AUbW94EjwQlcjJP31AuozWXQHO/SkuwMCpVrgTxNXTinM3q/gkEI2x9aYoftoNoFW8TK7bRfRCinXlM5kGCZioAFQ== 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 IA1PR15MB6222.namprd15.prod.outlook.com (2603:10b6:208:453::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.6; Tue, 8 Sep 2026 13:30:40 +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.005; Tue, 8 Sep 2026 13:30:40 +0000 From: Aditya Kamath To: Ulrich Weigand , "akamath996@gmail.com" , "tom@tromey.com" , "simon.marchi@polymtl.ca" CC: "gdb-patches@sourceware.org" , SANGAMESH MALLAYYA Subject: Re: [PATCH v2 2/2] This patch adds support to debug thread local variables defined in shared libraries in AIX. Thread-Topic: [PATCH v2 2/2] This patch adds support to debug thread local variables defined in shared libraries in AIX. Thread-Index: AQHdO7j67pBd2DaZoEysvNbW7bycjLbErPCd Date: Tue, 8 Sep 2026 13:30:40 +0000 Message-ID: References: <20260903085614.39532-2-akamath996@gmail.com> <7281fbc584ee75003dcd6fb8b2f41db739d68c96.camel@de.ibm.com> In-Reply-To: <7281fbc584ee75003dcd6fb8b2f41db739d68c96.camel@de.ibm.com> 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_|IA1PR15MB6222:EE_ x-ms-office365-filtering-correlation-id: 5d521af4-fa33-40e1-26b8-08df0dad6055 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|1800799024|376014|23010399003|366016|38070700021|10067099003|5023799004|11063799006|4143699003|56012099006|8096899003|18002099003|22082099003; x-microsoft-antispam-message-info: D60AiMvmVvpSHYTGkBAUFIM82nuZ3MD7qT/bd6mFdsvaQFKMUCDEV3HgWXPAxs6kpYSiHvO28iSk6jo3eB+sRmeHYrEkiJTcepN88+JrhtV+QAzwmBg0Pg+4o+r00I9Q9hZIMH8gBjtPtxEs23RzsBPrlCLYnx8ZnjSe1ac0JTWzuLdmqEV8rvZ0BrzRR/3X/IDJgVKtPjBDPvwyzGKRH3O7a0+Fa8zPHugQqYKM4L2WT5qa3drWl1Bdl6TgxVme/LKga71XdhlNxynuThqsLN0rneE5XRs+v6Gm9c3Vt3XXokI47SNzqe7N0/Bf4xTAa1g2kXHwPpkCaQZnZy/iwGEhO+fZgFhQjAdR11CEmPMFxSUGzOiGCAu1E1D/9e+iOWEl4xAdz64uMBOmj8pFENJhnuLQhXSsVoRbHLAMR0Q5OcjE1tWCDf1UIAcZZPRhBPm1Q0URKidIZcQzjof1RuFNIzKA+yE7JE04Wbpa25ck5o5t9oRGTcIk4KTMU35EHYWAmfULe8W45IlNhOMF9m6Kn/jN1JAlA6f2e8iBsyBxd3rBi6gP6R245CBuB9J+zy9HfQidjyjIFPNLWweVd1us7aTWq/rrhZnrqmnlbT7QPa7SxtkAJbNnX1ocPx9DOt4Ka0M9eXjpERl6N7am6T2VMNAdxl24d+Wrhm/Zl459Pe7L6KHkc9GEhEjtYi2CX1zPkmygdDnAnIpz+I+K3oqlcmLUUDKN1bJmftuib4c= 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)(1800799024)(376014)(23010399003)(366016)(38070700021)(10067099003)(5023799004)(11063799006)(4143699003)(56012099006)(8096899003)(18002099003)(22082099003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?himdH1iVSN2eRTdhBNpSWnmigtGIVgJiMhFiFPlAMMWMl0qxGTVCN00ThsCm?= =?us-ascii?Q?2PsfLzdBuK6pqXBbqoxeC7km5uqLhWPrGjJJf5NUybuNVTmsKzgEF3vthWpE?= =?us-ascii?Q?+G6rfTQs1K+FGJ0o3EN8xcpKEOoFP1UZDB1AdZr0NhZY1hYGdNX+3gddQb9Q?= =?us-ascii?Q?T7iunjWwSIr0BO21v+uinpzAst9VZkN+FTiVLiLjQBgMvH+/cWIQ4h9P5jtI?= =?us-ascii?Q?LKPQVfCwfqiqnGscLmAt6vbscVAn7RLG8+Xggw+xfs+3FtV36ZFXFlo5iy/T?= =?us-ascii?Q?3fy8DTGYPSUrVD7TwShU1YahSgAXogHGMMVR/maRW1nAxkEkbreWGtIoY11K?= =?us-ascii?Q?JcoN1gm43xPsFqT5zrFL4kPdP3y3HXaFlukUd7c0Inn2Hd0k9C0n9W64oPEu?= =?us-ascii?Q?OeLeVB7OTVZ+p+7TPD+KtIwJcVauwlVwfRyD9uOpwuclV5QjyU8BsIO9JVXi?= =?us-ascii?Q?3HFVepB3ZvDg3JrNR47UTCbeihCCgyJM+BnXwqBnKnsSYIgcbkqq6Mzu3cvp?= =?us-ascii?Q?HnGTaykGNIw95xuNEINI9NvH66POqr+/ClKqx2G4+FXRP0v90vaQthaobIS6?= =?us-ascii?Q?gL4i0QzcxW/4uepjGMeoR4VEhCiAZnz/WWC1EBtdjJp2UXXInaTnwMdX6ZzE?= =?us-ascii?Q?EMAV+4KB2nEihqFxHs4Qw9k2j+vcUJ6K1EhUw5wrXWX5m4L3WKjg8LRGqQO7?= =?us-ascii?Q?Xsg9nfHN3SH5GQVUFKi83JObfktKKIyX5AQnnkCGD7oSUVxXTYRPg/YmN9fl?= =?us-ascii?Q?+4hCfXm46e2rir+8UONbXSOydiP1B3z0jQyn3/b+ErdxWQOimFhOKr+uziPf?= =?us-ascii?Q?hWd9/mQDmYWj51NAghhhxRI8TzlRBv7a1XdLeAsFKdwhM2kACCnp5YxeJd7W?= =?us-ascii?Q?8pFrQR95ay7PfXMAWiO44nWzLYOzn+UkvItbfAkILcDkp0f9APdLCYIb450z?= =?us-ascii?Q?g6Rvyl8DOcjy+dPOASDs5gdxXQl9UMHFuTHuwTwAzDVTVReZJjZN41yjbvaA?= =?us-ascii?Q?sTgNXEeLklZgoVY9gOXwvYNt5EAxAbd+MSgXaUvFcucGkTIq38bGF/r5F/ss?= =?us-ascii?Q?hGc3Z1F3w9+0JgiiYSKu8aMLEgyThHGx7rRlViPc+C4Dtzjr3ecEV1k3C1Fq?= =?us-ascii?Q?c3EOOa+uBiy+3TLsX+jx2Pfvhq3wl6DDWjeGHIzLlp5+b0qWEdG7YYlKpH2d?= =?us-ascii?Q?mB0tvUI7PjJi5Or8ZhIMgVA0kxYeOfDeq+Mr3ZzGps1+3ngaGqJHjKP/WsD5?= =?us-ascii?Q?IO/2MGODyfPIQY0Qf2F7Vf9pRZDrtfigDOh0n4yZfkVyU7ek+E+WxTjh+DO0?= =?us-ascii?Q?ihOYLNmqMNvGlAi3US/wdFSci4hWo6baT8jOnnDhKGnP/o39GjKZJkSFD9rZ?= =?us-ascii?Q?wI0u9wDb3hEMZnJQ2rOzvPVaBPE/nJ+rURtJIS2tjYkwFp1NloJIkFbusJuA?= =?us-ascii?Q?MlEMd8/5E7jw4cebwtEHeJvY1W9Q/0LrpfujTykYfMaxV6RDN3Yo/3XTOy4f?= =?us-ascii?Q?hzx5lKM+uVCf9qKtH+hxWp2PS6H21cGwd8r0HEz0UTbjAHdVnPYqDnqPERkg?= =?us-ascii?Q?JM2T5WYJdXU29R/JUaqXicP6Z33w0DTvabGb1UH4+htFIJ6zjnHy5/LhKtrK?= =?us-ascii?Q?upY2obeco2u7e1Y+efeVvUOTLSsI502GtohM1HexO3IyJBBPDHflSZfswWQp?= =?us-ascii?Q?4YYmk+jmZsHenHmOqevAwZ6ezh+a6M7iWk41ypzxnsBGmV4ZIkdWSs73mA3C?= =?us-ascii?Q?FAryDTIV0TdIrhC7XXixds0X49n3OXo=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR15MB6488319B0A7CD3689309E7D0D6B12LV8PR15MB6488namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: BZSmRfEaaB4SXzpOFWoClj246bQG84K6smhXqJesJup3DiRkmLKSwaEwiNMIAFmqZ+ozvF3OpT0JPK1H8OZF/fYYDsb2oq2gqIAlqa31nyzVMwCZ6PYerqQwJSQySXj6RRqaqk8JfyPhfGO4qzAEYOWVXb/IxB+Bcj+XJCGzbEcDnzZLlZY9ISgDAEokLFUB0gmCVtCqOlsgraKQdTb6o2OkX5A25fbNjhYUqlm6LP3QP+RATZ+yBmnVe0MI/zFhgNiQAYhjpNIDvfmRm8N2lSJkrg5mzoeohbJtmVVu82zEJLRwtZ1f1PSROkfK9rc3GuecydTs9jLsjhW59Qq69g== 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: 5d521af4-fa33-40e1-26b8-08df0dad6055 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Sep 2026 13:30:40.6074 (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: DkU3KDaBaIkgsbmDPRGNEr/BPVhSsKI2Tp96z9ZKbCY/urfZMI8sZgtsPvm7+4eoHamXL64IA/6wL+YGMav95A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: IA1PR15MB6222 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Proofpoint-GUID: l2nsA4g7M2KuVFQAe5Q_pYFzdxQylvz- X-Proofpoint-ORIG-GUID: ozQupHoWUic9HjTAtMdF71tFRUF85FLW X-Authority-Analysis: v=2.4 cv=RNCD2Yi+ c=1 sm=1 tr=0 ts=6aa00e20 cx=c_pps a=I1DPz4bLegk/AyvijR/I8w==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=VdqzKS8jKosA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=fMcteMqnr-rUd66IqFEA:9 a=CjuIK1q_8ugA:10 a=fV__o4OLm5_YjL_ZMBcA:9 a=n7VJHsyuUPJjdnQp:21 a=_W_S_7VecoQA:10 X-Proofpoint-Spam-Info: AW1haW4tMjYwOTA4MDE0MCBTYWx0ZWRfXyVhDffa9ONbf PrOttQuLlGef8rx5wV29tbebofVVhV9sfeT6V0a9gt2kDF6bdTrrMZoKw3g7ii4bFShfA8Vgnuh MyU9IzDjmcLLBPXUz7D4uIaZg51V1Mc= X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwOTA4MDE0MCBTYWx0ZWRfX65ptcLktAtq5 993/Ef308CBEtj2Z8tRg2k2qJ693v2uwy39fSmWf6cb3jAUL43JX2V8KUFElpmRz4EOo2UALBd5 wxZ2RuZNrPN283+JMjpdijSowwWmxLR0befsNk1GxvsahjZj3BxrAENRQX85mkl6FyD7ZVCkOuP ZSaxm3Py0LqM9n1dsPbMbEOByq5E6gZfcxMIiZlwAv3kEpm53oFVm7kQFsN8OAmpPuYGry+dnKh Xtemny0/jxD6nodwymqsvADSB1xGyiraS0Fl/OA/QGJYOzyUWTHPhFUcr2N7SdjHqhBXX9WV+6o Q5atc8prbO63FruqOCMv9JLbaGeqwCmnoWo9R0gLqeWoruF5rUYTh8Ze/XTng3RzSeg/4a82uPQ PJAfowQMgDpSSiYFtWDF4HQ+TACL9bTxiRS5ytWY1QhDLl6O6LvKIqiPisyxByaickf89NOASU8 q94lTxfxKT32Aiy/u+A== 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-08_02,2026-09-08_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 clxscore=1015 spamscore=0 impostorscore=0 adultscore=0 phishscore=0 suspectscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2609080140 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_LV8PR15MB6488319B0A7CD3689309E7D0D6B12LV8PR15MB6488namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich and community members, Thank you for your feedback so far. I am sending a v3 patch of the same add= ressing your concerns soon. >If you have two dynamic libraries, both defining a single >TLS symbol, they will both get offset 0. This is right. I get why you Said this. That is why I decided to have two s= trategies of which in strategy 2 of the new patch we match R_TLSM by symbol= name, i.e. by reading the loader symbol name from the R_TLSM reloc entry a= nd check whether the library we are looking for exports that name. Symbol n= ames are unique under dynamic linker search-order rules, so the first match= correctly identifies which library the slot belongs to. >On the positive side, this means you can do the whole reloc >scanning fully in the fetch_tls_load_module_address hook >(since you only need the objfile - the offset doesn't help >you anything anyway), and simply return the module ID from >that hook. rs6000_aix_fetch_tls_load_module_address () now does exactly this where it = calls rs6000_aix_find_module_id(objfile) which scans the .loader section us= ing only the objfile and returns the module-id. The offset plays no role in= module-id discovery. >(That means you could even cache the module ID >in a per-objfile data structure to pay the price only once.) The aix_tls_objfile_data struct attached via aix_tls_objfile_data_key imple= ments exactly this. After the first call for a given shared library, cache.= resolved is true and subsequent calls return cache.mod_id immediately witho= ut re-scanning. Please see +struct aix_tls_objfile_data +{ + bool resolved =3D false; + uint64_t mod_id =3D 0; +}; One more thing I want to tell is testing in my LPAR with the test case patc= h, I found that the AIX loader assigns module-id 0 to initial-exec shared l= ibraries, not just the main executable. The old code treated mod_id =3D=3D = 0 as "not yet allocated" and threw an error, which broke access to any vari= able in a library loaded as initial-exec. The v3 version of this patch remo= ves those checks, and adds rs6000_aix_find_initial_exec_tls_offset to handl= e the fact that for initial-exec libraries the static XCOFF symbol value di= ffers from the runtime TP-relative offset by the size of the initial TLS la= yout shift. So these are the changes I made and am sending the v3 version of the patch = to address the same. So we have three patches: v3-0001-Add-TLS-variable-debug-support-for-AIX-64-bit-XCO.patch - Already s= ent v3-0002-This-patch-adds-support-to-debug-thread-local-var.patch - With corr= ected things to review v2-0003-Add-test-cases-for-all-TLS-support-in-AIX.patch - with corrected c= ommit message. Kindly let me know what you think once I send them. Thanks for the guidance= and review again. Have a nice day ahead. Thanks and regards, Aditya. --_000_LV8PR15MB6488319B0A7CD3689309E7D0D6B12LV8PR15MB6488namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ulrich and community members,

Thank you for your feedback so far. I am sending a v3 patch of the same add= ressing your concerns soon.

>If you have two dynamic libraries, both defining a single
>TLS symbol, they will both get offset 0. 

This is right. I get why you Said this. That is why I decided to have two s= trategies of which in strategy 2 of the new patch we match R_TLSM by symbol= name, i.e. by reading the loader symbol name from the R_TLS= M reloc entry and check whether the library we are looking for exports that= name. Symbol names are unique under dynamic linker search-order rules, so = the first match correctly identifies which library the slot belongs to.

>On the positive side, this means you can do the whole reloc
>scanning fully in the fetch_tls_load_module_address hook
>(since you only need the objfile - the offset doesn't help
>you anything anyway), and simply return the module ID from
>that hook.  

rs= 6000_aix_fetch_tls_load_module_address () now does exactly this where it calls rs6000_aix_find_module_id(objfile) which scans the .loader= section using only the objfile and returns the module-id. The offset plays no role in module-id discovery.

>(That means you could even cache the module ID
>in a per-objfile data structure to pay the price only once.)

The aix_tls_objfile_data<= /span> struct attached via aix_tls_objfile_data_key implements exactly this. After the first call for a given shared library, cache.= resolved is true and subsequent calls return cache.mod_id immediately without re-scanning.

Please see 
+struct aix_tls_objfile_data
+{
+  bool resolved =3D false;
+  uint64_t mod_id =3D 0;
+};

One more thing I want to tell is test= ing in my LPAR with the test case patch, I found that the AIX loader assigns module-id 0 to initial-= exec shared libraries, not just the main executable. The old code treated mod_id =3D=3D 0 as "not yet allocated" and threw an error, which broke access to any variable in = a library loaded as initial-exec. The v3 version of this patch removes thos= e checks, and adds rs6000_aix_find_initial_exec_tls_offset to handle the fact that for initial-exec libraries the static XCOFF symbol value differs from= the runtime TP-relative offset by the size of the initial TLS layout shift= .

So these ar= e the changes I made and am sending the v3 version of the patch to address= the same.

So we have three patches:
v3-0001-Add-TLS-variable-debug-support-for-AIX-64-bit-XCO.patch - Already s= ent
v3-0002-This-patch-adds-support-to-debug-thread-local-var.patch - With corr= ected things to review
v2-0003-Add-test-cases-for-all-TLS-support-in-AIX.patch -  with correc= ted commit message.

Kindly let me know what you think once I send them. Thanks for the guidance= and review again.

Have a nice day ahead.

Thanks and regards,
Aditya.
--_000_LV8PR15MB6488319B0A7CD3689309E7D0D6B12LV8PR15MB6488namp_--