From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id SgGGENKmeWrRGBoAWB0awg (envelope-from ) for ; Mon, 10 Aug 2026 06:24:18 -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=QdEYclZM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 31EFD1E033; Mon, 10 Aug 2026 06:24:18 -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 [38.145.34.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 3C6331E033 for ; Mon, 10 Aug 2026 06:24:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AC6FF4BA79A5 for ; Mon, 10 Aug 2026 10:24:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AC6FF4BA79A5 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=QdEYclZM Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 943BF4BA2E3C for ; Mon, 10 Aug 2026 10:23:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 943BF4BA2E3C 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 943BF4BA2E3C 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=1786357426; cv=pass; b=OCH7SRc7Nos57zxCgfxZE0svzy9OE/WFOU5vrsEJG9re45dXZAUZ8Cop5gW+fghhOinRDrSyR16Y3RqsmfLOBx6sDn+myyhYjC0FzqpSQhnazVWrusONn3bp/h5hNsJJD9OaAt5FnsvAqFqehfUcsnTaZ5WAApWXGq67CF6ePnk= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1786357426; c=relaxed/simple; bh=BpzmcTCr0cMcyQeAG5h0l1bH5hvo+Zd47nhmaaAnKL0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=nVIri2bv3AHYoItcSmXEzAz/VNTi1E+Bpn+KpMl0Osvwe9cAczElTAarem8LaqIsM3zO+HkmLRVHHG4ZA8qE2Xff5uOm53R/o4a08Fd6rAuQPC6tN/2ofZxrjAzKpXUDRY0xJAyiaF9HLec+g/5jMLTJRAFB1pFPAIqm7ZFkAbE= 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=QdEYclZM DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 943BF4BA2E3C 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 67A9W0XD1170193; Mon, 10 Aug 2026 10:23:42 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=xnA32F0TWNTUIcyhh+7Yj2K1SCl6yG 6NCmZlRDKj/kc=; b=QdEYclZMarPvqb1kJ6gnZ4TSSIpeqcUHZzsHHc8VZTvICt KQUDryLGiQqrInAi/N4ZvWjto021wjktgmHFUQFBGD/zzWqntG2dc6+Ogp0Kf2YB vAK5va4cMjsEkHfA/RASyRL6mrx35S3dfgBbzOmpFWEgEC4IRnhrGzJ54PVcJeGk 1g7RfgUaOmBgS09nMDm/R9LXU3cHYmqMocaXKoA0GkyT0WD4ZOiIH2IFzcul808e OCpkogsPNC+j45zZuskgeW31FjsFrZC5JyvgnhUXfLGz1L+Xm6nEQJkrYf1j21Wu VZV33lFwliNk2xLIeMBayG5g6T8lj4ZWklsFk8Og== Received: from cy3pr05cu001.outbound.protection.outlook.com (mail-westcentralusazon11013057.outbound.protection.outlook.com [40.93.201.57]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 4fwvp2q37e-1 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 10 Aug 2026 10:23:41 +0000 (GMT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=mR/oAubvaZiPnwJdnUryS4Vy7hI0EfWRKSXixRtT8nIONjgeYrPEO0JqjK6Swx6USsR9fJKbJOGLfGbJ518x9QGYSz54sL95yiLXe1VWxO46/eq+ve3HiAsZtQW3ZHRbNZUOcB1xrMdQN4oaMRgB7pcfKFrSUIIqpevQB34Ekh69fJdEHP85SiYL5ikq2KcFAbWud/WptweDI2SRqz2UUK7Yg5XA1ulkfUZLteEOlqvldUvhgZtOfoqDOBRTF/tbwMJ2Sp2BSL9H6Y6QNYIRctmfCoMESJ+z5cZ3zgz4mF1nqQ46IZtomRdbPKnzyJpxz87IF3phcEk5IQDDINm4PQ== 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=xnA32F0TWNTUIcyhh+7Yj2K1SCl6yG6NCmZlRDKj/kc=; b=Y74th4aXeKxbvjz9xf2VVe0Wf5eq9hvqU2JfkMhJwf2PhU4ZxQu7CF9EMoCS795/tS9iHn67PBEeVnjZ3jdu0dvldFXDm5ZAukvUwvujJHncGnx/d+DXYtgWHin8iN7KUP6lKlNMgj6SIVQmO+NK5W8e9gurpl28l7iPLr6w6wBJZMU8mupJwjNwJ2hQzWNIYvRsacZkfzE602MEpTZrusM5AePQ4b2s1rtoAJco5ZivtAMFmCWKMMgrB3fvTIca56fkp8SPTo/FUmmb4e0XCd9dgyFKUA9FMY15GNY7QjaCBpgsmVuBF20mEtCkWC8zJd4PuDaoMvATX/X6zVgVcw== 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 SA3PR15MB6148.namprd15.prod.outlook.com (2603:10b6:806:2ff::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.25; Mon, 10 Aug 2026 10:23:39 +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.0292.024; Mon, 10 Aug 2026 10:23:39 +0000 From: Aditya Kamath To: Ulrich Weigand , "akamath996@gmail.com" , "tom@tromey.com" , "simon.marchi@polymtl.ca" CC: "gdb-patches@sourceware.org" , SANGAMESH MALLAYYA , PRAJWAL B MEHENDARKAR Subject: Re: [PATCH v1 2/2] Add TLS support for shared libraries in AIX Thread-Topic: [PATCH v1 2/2] Add TLS support for shared libraries in AIX Thread-Index: AQHdJO1YfVJEEWssH0y3Mu9mxRZPIbaXEM3R Date: Mon, 10 Aug 2026 10:23:39 +0000 Message-ID: References: <20260803105911.74857-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_|SA3PR15MB6148:EE_ x-ms-office365-filtering-correlation-id: 06886b59-4a25-4ccd-1d5a-08def6c971e8 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; ARA:13230040|376014|366016|1800799024|23010399003|38070700021|6133799003|4143699003|11063799006|56012099006|10067099003|8096899003|18002099003|22082099003; x-microsoft-antispam-message-info: wfOg4fdI5bTgoRRVcnev1cUrwwVujNy0iV5ye8Ssk4/I45oYi5htayLAtKf7ufq5Y9QeJqkRf6FEnuNaTgT79wuNXE1wGKxVV3gyxqdgxIcecB35He1ggwqwbbnppNn2DBODQeNtOlFfbQH2IvU7USiBF81NcZL4ZIFPGf/hmHcz/WEk709QoKmBePWr/FqJcwrA9Q1IEfpz+M1AmP88z5img1eW8w/vr1KSKGU9vnUGlPaQLt9GXkUXooR3aKgm/lO9NKWoPv44e+A+ewEeTaTk3OmxCYH8PoVmkWxdsMWWQohu2uG3lyU/757vW9RwLpR1ORXdp0MZSqZgwUkbSz+dQ6Ig1PqTbpLIEyDoN3E4X8eZfrIcbi2NvgOMB1mGovfR6dCBV3JZXKqOLw/zk211Ia6dI2KNZjX4RqB13Iv7X8NA+vBeiVrNaAy6CtTh/qMkhDoKd1yNlzhNQ6smsdYy1SFeVedMxfQC+zZ7ATuXtMJblUdDb/CVYAUXTVq7V614I4sljeWE8V+4/fFbxENE3z2atX9KPtH3Fb1ZIbrTNkYMvpPADg/tRJK6MKsxHQA0p91t1zI7myAz6caOB2o1SGx1WGpP4Cc8mXNoV9YzMwoUdZLuDMi2q6xjv4tEh57coZeA8bGlanxkH9NmEzgD5o2Dp6fPvHDNP6XWq49CAylzZRd/eg5agoOWLk035w6MJLCD2sDtcno23yOF+nOrh4atHpHM7ITKTd7pzKc= 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)(366016)(1800799024)(23010399003)(38070700021)(6133799003)(4143699003)(11063799006)(56012099006)(10067099003)(8096899003)(18002099003)(22082099003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?9lWnhKkIrcm0J5UThVokdUuuh1f6OOGl8KoiYq2xgeTspulw4rN5FwXhf+ck?= =?us-ascii?Q?cuaeZ6WOjtfgoG0x7EaXZJ2RWVhNqDzdvuxBzNKgBvpep63EO6/P2RInlYD9?= =?us-ascii?Q?LrX3MBlsQGa3kLHXk+2CpAWe/9d2VqGz83FnGGnVjZqCAnWu34m6/Z66d4rD?= =?us-ascii?Q?VVoxBxfvD3K4IJFQIC2j76ylKlEDz3DMguKJUIBrBkYf1HSMAzc2K+GAZlG9?= =?us-ascii?Q?tJAJU2KJbub7PiWh9dYql67z5bUrXnBfY9pyMpOYIiwXcKiM+YEOmj1COlwJ?= =?us-ascii?Q?r2zrLPryoBxDOFzWC+or8tZGesYYDqpMV7M8/vRO74NcpaoixcSLTlPFzi30?= =?us-ascii?Q?YL6Q29gX28e/9IuyTf+eIFfNmLWAgAKcDJFqGd8ycOxmO/ewgrwztoRRVAGA?= =?us-ascii?Q?mxXaHjCA6sZNo+ZdJjyxV8xX9y5hVsANcICX32wgwK5DnjrecYwdqq6M+bLa?= =?us-ascii?Q?neTW/BRFulCKMUoWMjxyZu02UV++9xRnVO/YYkQ/x1W9mXufxw6aSuzkliuQ?= =?us-ascii?Q?sLfxreiHagg816keiUePVr99dzCtsavd94AiHHAHsYdXj4tlko6MgOHl5tfT?= =?us-ascii?Q?jvP+7he3y1H45wZdmfp76s0UdXMXc+LCAucHbApVfpmvO0H3QPvQSQzNYTse?= =?us-ascii?Q?z0fF1Hu2AZY+ziFx7KzpcZ1TqYnzWeBAl47GfcT6xFjTcJ+lRKNPT/PftgYO?= =?us-ascii?Q?0Oi/h9j6ms2OKHkCutYJPvKauLWQ064yu6NFtisHb1aFQ9qsSJ71iC9Jk+gZ?= =?us-ascii?Q?qj5bSlFWthSq+Z8qzRQwChWdunXXC6gvnUemTEfUKQWKJWG2aY6c6a8IXyhl?= =?us-ascii?Q?ezEzTLxawyhsquZ/+KzvRioa86CMuzeaTBPAQ5xgTYC0ZY6zUrwf9c+idP+x?= =?us-ascii?Q?Virkj+OiE/ORPpPw1aUYZ1T37CIGsHhGy2aY3oarG8DMPaPZquig1sa0ugqS?= =?us-ascii?Q?GIOVFZ2Ea8vUBk6nj7urZYcc1F7oGyLaAUWAdCAVtMVskQRStybajgyvjrQ/?= =?us-ascii?Q?rvLtZ3gokdxXRehR9r/T6jY0pQ34+rbfj2VMas/XDrUC07qSUSoCYw+cFkiB?= =?us-ascii?Q?xXKn0oVLboc6QxrMKhu1yv28+til3gf4zyY73mMcXi/0AUk7kNIsDeeNkbVS?= =?us-ascii?Q?kAgCipOeB2Q2dZFA3bdsB/aVttwX4Dxp79wWUyvKThfPT6ViSzOcYdIJ8ncm?= =?us-ascii?Q?R/K3xwHGbx14MYZHwFv07s3qZBrYCxMHHtZD2rob2bMLVmOL9h7nIWdrWY7r?= =?us-ascii?Q?GHUopXdTaCv8EopZa58Acl8WUEElN0PSAj+tQl/xxh/B+NSyxJCqhUUHqzw7?= =?us-ascii?Q?noM2ut1O0BtYBU5jjuhij6ZfQ0pPVWZmZGVgh9rNpyCJr6K63As9EoPvBs9M?= =?us-ascii?Q?YkFWLf+fK1XGErVm9yGBQLqE80kysdsej2CuuWQ2GBNC3U5di+0ggqrw5yBR?= =?us-ascii?Q?vdva09rchzbtAd9R+8PTgZgxNChZLHNsyvflZPEhOAUbqA/fyZdITDyg2LHY?= =?us-ascii?Q?kj4DCG50toIpqZiQhqbZeT61nrIGXKReFspWAyHIvnu4drVjV52cFJ7WUmk2?= =?us-ascii?Q?R0exrTfpH/xXfi5VQpWD00NP9J9idEoPcELXh1Xjl7Y1w/5P5+Ig4zvOhMiY?= =?us-ascii?Q?Rag0AVcK15k2z9U5OJSnepwn77oaBdGAdD7+GtEPIU4sKq0eFrsrYt4JVybO?= =?us-ascii?Q?daTHRHDybnLVg4LECaaRD6u5PVXWE6llFQTab79L6qxQd6OIXCNK1+zsjNOt?= =?us-ascii?Q?KbZzraLk3bbCTZX2okJwHNsNq9ea6r8=3D?= Content-Type: multipart/alternative; boundary="_000_LV8PR15MB6488341D3020AD837DDAF3CDD6DE2LV8PR15MB6488namp_" MIME-Version: 1.0 X-Exchange-RoutingPolicyChecked: jqmYIB9uibQBmgzKebqgVqU6uU07ggdvOxW+ZMUwBSvXJQYxI4xglLRhzpxFqNyjOY08Uk5geL3VHKW4BRgg5KM8HCbL/wL2yIBUvyN7Wmx10zJvObQJu5cXbeCwcGQLGPji3qEFJ+qvCdMbNSxKXgzoQd/OoebSyUxC4bOKlrQbtJb/v2prGj8zorRp9kFK2XixqbEezUGlfxZZCqJ0DH812YNcTN/hSyAW3WKB3ZtzWXUWtivmdijOPuYlOHHm7YqfQ0kVZDTR4HkhtYsmbKQaVaOJIasTw0w0JPaKWLnZh5VV0UL6j5leQkusCjP2ermnQk/6afpXdyQTr/Pfdw== 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: 06886b59-4a25-4ccd-1d5a-08def6c971e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2026 10:23:39.2293 (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: djQsoUQSCzfd1qc40LXgUSZU+aKzn0bZjuClAESoKk4GLWI0FWxLandnBDIzF5dDqzjPXcjv6M+634H9YUoh/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR15MB6148 X-Proofpoint-Reinject: loops=2 maxloops=12 X-Authority-Analysis: v=2.4 cv=AMtp2X5w c=1 sm=1 tr=0 ts=6a79a6ae cx=c_pps a=+XPUo/5NTXuj4we3MZHZ5A==:117 a=z/mQ4Ysz8XfWz/Q5cLBRGdckG28=:19 a=lCpzRmAYbLLaTzLvsPZ7Mbvzbb8=:19 a=xqWC_Br6kY4A:10 a=Sv0fKeRqtYgA:10 a=VkNPw1HP01LnGYTKEx00:22 a=RnoormkPH1_aCDwRdu11:22 a=Y2IxJ9c9Rs8Kov3niI8_:22 a=kVAN-hXKyEDRCqnaX1sA:9 a=CjuIK1q_8ugA:10 a=H3mWlfXF3ue16yuaLOwA:9 a=Y3xgDKTpG0vAxLS2:21 a=_W_S_7VecoQA:10 X-Proofpoint-GUID: uJl6rwZzUAZFiGwSZaj2uUXXU99PjncQ X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwODEwMDA4NyBTYWx0ZWRfXyH2jBSfhRxoG fWcIbO26F1a4xXYuFe8gqahtT2tLZRl6uTLeK4QScvUD+IEthe+ht130B4WeV69B3eWqjFG2oI5 H9G462Bi08VaLqnOQ4qP7x4R1loL3/Klt8g0LviFEiVJrsDwgRUosMpnS6/eGpxU8mlixeXmDah PLRhPhN+dCKBTqJgAZFvceTLwY97BID9S6t0uUbejxFHZ0GJN8mVkr8IayE856EJQUyRKJE6K// Bp65Yd0nrNLfsaDIgtVQiKgcJ24MgijEc/KYhxn6Fxy+FZUZuGgWSEZnQbhdJVM8WkMK/W6zZfj NCvjDwi16ZEniN+ji/XnMIJaJyY8p/WTrcai+CRzsjTCUT+xtCc99mlScZlEhAykub24VvtE20u c/YpOfr5ftSzoUWCgaBWIZVo7VkUt91i7AmyubzQ/DProX/R9gpJ+9Eb0EfNx2tGoS39iKc0BoJ ftOs7trmgbhhhJvGUPw== X-Proofpoint-ORIG-GUID: N---VM4oGQvYSCLEgTlpB3bMATrNyVR5 X-Proofpoint-Spam-Info: AW1haW4tMjYwODEwMDA4NyBTYWx0ZWRfX/+XM1PkIadlc 0qU81gO1o29F/Hd/KcyQZHmhoUwx1KV01KuzrJZus229BblGlS9BR0Et/1HLkXnCBIuhL+oA3/g SgXIthc6V8UmOIPXl0t0hR/2UgsjuLU= 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-08-10_02,2026-08-07_01,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 adultscore=0 lowpriorityscore=0 clxscore=1015 priorityscore=1501 impostorscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2606150000 definitions=main-2608100087 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_LV8PR15MB6488341D3020AD837DDAF3CDD6DE2LV8PR15MB6488namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich and community members, >This is an interesting approach, which is quite different from what >Linux is doing. The one question/concern I have this: are these >relocations present in the module where the TLS symbol is *defined*, >or rather in the module where the TLS symbol is being *used*. On >Linux (ELF), it would be the latter - but I don't know all the AIX >(XCOFF) details here. >If it is the latter, then this approach has the drawback that the >debugger can only access symbols that are also accessed somewhere >within the program being debugged (in fact, with the current patch, >only symbols that are used in the same module they are defined in). >With the approach used on Linux, it is in principle possible to >access TLS symbols whether they are used or not. (If there's no >better way to implement this, that of course may still a limitation >that can be accepted.) >Either way, it would be good to add test cases for the various >scenarios. Yes, we are on the same page here. Let me take this opportunity to explain more and give more information. # cat tls_lib.c #include _Thread_local int lib_tls_var =3D 42; int lib_get_tls (void) { return lib_tls_var; } void lib_set_tls (int val) { lib_tls_var =3D val; } Assume this is my C code that I am using to create tls_lib.so The way I am computing TLS variable address currently is dump -X64 -Hr tls_lib.so | grep "0x0021\|0x0024" 0x110000528 0x00000018 0 0 0x003f 0x0021 The above gives me 0x110000528 - reloc type 0x24 (R_TLSM, global-dynamic) o= r 0x21 (R_TLS_IE, initial-exec) which is my static TOC slot address. CORE_ADDR toc_addr =3D ldrel.l_vaddr + objfile->data_section_offset (); The above line the patch is doing this where ldrel.l_vaddr =3D 0x110000528= . bash-5.3# dump -X64 -tv tls_lib.so | grep lib_get_tls [16] m 0x100000480 .text 1 extern .lib_get= _tls [20] m 0x1100004f8 .data 1 extern lib_get_= tls This gives me static address lib_get_tls. /home/aditya/binutils-gdb/gdb/gdb ./tls_test Reading symbols from ./tls_test... (gdb) break tls_main.c:36 Breakpoint 1 at 0x100000a78: file tls_main.c, line 36. (gdb) r Starting program: /home/aditya/tls_test/tls_test main: lib_tls_var initial =3D 42 [New Thread 258 (tid 131072299) (id 2)] [Switching to thread 2 (Thread 258 (tid 131072299))] Thread 2 hit Breakpoint 1, thread_runner (arg=3D0x1) at tls_main.c:36 36 volatile int bp_here =3D 0; (void)bp_here; (gdb) p/x &lib_get_tls $1 =3D 0x900000000e42480 The above is the dynamic address of lib_get_tls () inside the shared librar= y. (gdb) x/1gx 0x110000528 + 0x900000000e42480 - 0x1100004f8 0x900000000e424b0 : 0x9061fff48061fff4 So the objfile->data_section_offset () is helping me to get 0x900000000e424= 80 - 0x1100004f8 which is the offset to the data section. So, the plan is to inspect the link time symbol table for the TOC entries a= ssociated with the TLS variable in its defining module. From there identify= the load time address of the appropriate TOC entries and then use the valu= es to perform TLS address calculations. Unfortunately, compilers [GCC or clang] on AIX will not generate the TOC en= tries in a translation unit if the variable is unreferenced. So, we cannot be in sync with the way Linux via ELF does. In Linux DTV look= up can be done for unreferenced variables. Even in stripped binaries TLS de= bugging will not work in AIX with this approach. Until this is implemented in both compilers, I would like to propose this m= ethod so AIX users can debug thread local variables. Let me know what the community thinks. Have a nice day ahead. Thanks and regards, Aditya. --_000_LV8PR15MB6488341D3020AD837DDAF3CDD6DE2LV8PR15MB6488namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ulrich and community members,

>This is an interesting approach, which is quite different from what
>Linux is doing.   The one question/concern I have this: are t= hese
>relocations present in the module where the TLS symbol is *defined*, >or rather in the module where the TLS symbol is being *used*.  On<= br> >Linux (ELF), it would be the latter - but I don't know all the AIX
>(XCOFF) details here.

>If it is the latter, then this approach has the drawback that the
>debugger can only access symbols that are also accessed somewhere
>within the program being debugged (in fact, with the current patch,
>only symbols that are used in the same module they are defined in).
>With the approach used on Linux, it is in principle possible to
>access TLS symbols whether they are used or not.  (If there's no >better way to implement this, that of course may still a limitation
>that can be accepted.)

>Either way, it would be good to add test cases for the various
>scenarios.


Yes, we are on the same page here. 

Let me take this opportunity to explain more and give more information. 

# cat tl=
s_lib.c=0A=
=0A=
=0A=
#include <stdio.h>=0A=
=0A=
=0A=
_Thread_local int lib_tls_var =3D 42;=0A=
=0A=
=0A=
int=0A=
lib_get_tls (void)=0A=
{=0A=
  return lib_tls_var;=0A=
}=0A=
=0A=
void=0A=
lib_set_tls (int val)=0A=
{=0A=
  lib_tls_var =3D val;=0A=
}


Assume this is my C code that I am using to create tls_lib.so

The way I am computing TLS variable address currently is

dump =
-X64 -Hr tls_lib.so | grep "0x0021\|0x0024"=0A=
        0x110000528  0x00000018     0 &n=
bsp;    0  0x003f    0x0021

The above gives me 0x110000528 - relo= c type 0x24 (R_TLSM, global-dynam= ic) or 0= x21 (R_TLS_IE, ini= tial-exec) which is my static TOC slot address. 

CORE_ADDR toc_=
addr =3D ldrel.l_vaddr + objfile->data_section_offset ();

The above line the patch is doing this= where ldrel.l_vaddr =3D  0x110000528. 

bash-=
5.3# dump -X64 -tv tls_lib.so | grep lib_get_tls=0A=
[16]    m   0x100000480     .text     1 =
 extern                  =
  .lib_get_tls=0A=
[20]    m   0x1100004f8     .data     1 =
 extern                  =
  lib_get_tls

This gives me static address lib_get_tls.

/home/aditya/binutils-gdb/gdb/gdb ./tls_test=0A=
Reading symbols from ./tls_test...=0A=
(gdb) break tls_main.c:36=0A=
Breakpoint 1 at 0x100000a78: file tls_main.c, line 36.=0A=
(gdb) r=0A=
Starting program: /home/aditya/tls_test/tls_test=0A=
main: lib_tls_var initial =3D 42=0A=
[New Thread 258 (tid 131072299) (id 2)]=0A=
[Switching to thread 2 (Thread 258 (tid 131072299))]=0A=
=0A=
Thread 2 hit Breakpoint 1, thread_runner (arg=3D0x1) at tls_main.c:36=0A=
36    volatile int bp_here =3D 0; (void)bp_here;=0A=
(gdb) p/x &lib_get_tls=0A=
$1 =3D 0x900000000e42480

The above is the dynamic address of lib_get_tls () inside the shared librar= y.

(gdb)=
 x/1gx 0x110000528 + 0x900000000e42480 - 0x1100004f8=0A=
0x900000000e424b0 <lib_set_tls>:      0x9061fff48061ff=
f4

So the objfile->data_section_offset= () is helping me to get 0x900000000e42480 - 0x110000= 4f8 which is the offset to the data section.

So, the plan is to inspect the link time symbol table for the TOC entries a= ssociated with the TLS variable in its defining module. From there ide= ntify the load time address of the appropriate TOC entries and then use the= values to perform TLS address calculations. 

Unfortunately, compilers [GCC or clang] on AIX will not generate the TOC en= tries in a translation unit if the variable is unreferenced. 

So, we cannot be in sync with the way Linux via ELF does. In Linux DTV look= up can be done for unreferenced variables. Even in stripped binaries TLS de= bugging will not work in AIX with this approach. 

Until this is implemented in both compilers, I would like to propose this m= ethod so AIX users can debug thread local variables. 

Let me know what the community thinks.

Have a nice day ahead.

Thanks and regards,
Aditya.


--_000_LV8PR15MB6488341D3020AD837DDAF3CDD6DE2LV8PR15MB6488namp_--