From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YZshFdwArGofLBcAWB0awg (envelope-from ) for ; Thu, 17 Sep 2026 11:01:48 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4D5DF1E06B; Thu, 17 Sep 2026 11:01:48 -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,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 7BD7D1E01F for ; Thu, 17 Sep 2026 11:01:44 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5092C4BA23C7 for ; Thu, 17 Sep 2026 15:01:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5092C4BA23C7 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD Received: from MRWPR03CU001.outbound.protection.outlook.com (mail-francesouthazon11011061.outbound.protection.outlook.com [40.107.130.61]) by sourceware.org (Postfix) with ESMTPS id 8F8284BAE7C1 for ; Thu, 17 Sep 2026 15:01:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F8284BAE7C1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8F8284BAE7C1 Authentication-Results: sourceware.org; arc=pass smtp.remote-ip=40.107.130.61 ARC-Seal: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1789657265; cv=pass; b=Ccmc3lKH8FJPI4JuzggZJoA9dp3zdZczLTvArK2MtcI/GOC93zCCoRW33sZCoVLbmcwKvRiWDXjmEcNsjrqKM4l20W2UluzENuw/mREA/ryHSP8bcuiQ5lhsRfEzebHA+oXyIeoiaywcM/svYC6WmLG6qKfe/K9URQ9LOwOPtG0= ARC-Message-Signature: i=3; a=rsa-sha256; d=sourceware.org; s=key; t=1789657265; c=relaxed/simple; bh=W+52wkwXgL/psXsjb8Uwfa/1PX2V02nkujNNPSxBZsU=; h=DKIM-Signature:DKIM-Signature:Message-ID:Date:Subject:To:From: MIME-Version; b=ajgj55Ym4pjluxzeqzP8Vlk7HkdEUMe5ed0+6Q21j/rd+K8P26PnrpnCnxtRgKsPWmPM0Od/u0iMGCLC0pY9vjLqjAvDIDe0Cdb/D4UpwBKT8/PL/hKRTUDAMl1PaLYVuGXWsJ5MBlZpSaPaAztc+bTp5Xf9uO4Czy+ntSo9KAM= ARC-Authentication-Results: i=3; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.a=rsa-sha256 header.s=selector1 header.b=GOlHNanD DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F8284BAE7C1 ARC-Seal: i=2; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=pass; b=rhGWY2mTWLk0tei/yWACwCX6+gDUDkVz2htgrEPbwty9X2C9+7kCJT56b/7N8hSKPlWCvCqEse4rJgx0qW0Pj+0ip4Tg8hwGTrhNlWmntAQ3kshuG7uY3E4RJiBC6AFYempbqvYx5Pd17dTaePVdh0/mfKK21gAgHqyKRS35RAolKG8dWxzYnyXl6alQVnZ88hEJDTyw9VGwtASNXTwGoxDOMKyt2ASfO3RtJi+oZR0kG84+k2tnkqtjKVBxa6Qvq0pjKO3Gj7EK24o3CnVHSuCE5CWJ5taY59mXC83EHk5mBj7WhddzPF8C1UKlrT/hUU9C9bSaaVyeQWzofv35ng== ARC-Message-Signature: i=2; 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=112ah4Lw84JS68PU9yP8+GtTiFEeYLfuQbAKiI+WVYY=; b=uf5T2EqIf+UKtSYekq4KH9gRu9SM7poDMllpO6TCnKyWxsml4VkCXdb85mj6cqrZ2ffDvdxrTnPdSyVlwKWjqUd1BR+eyQcW8Omp4v2+wQ3m4ZF/d9G3jJqYxrkXTxCpAG5OPv00mP7lUKLVnPPwaoevxRs3RNSyidPYcjgORYaRjB6I/iIJMBhNy2N5NesZwOJ95zal6ga8J39ZM4PTcf5UfmyMwrmlLzwQRuqhLqOd2EXtlfsZwK1xAF4QRl8PwtvohzPCnF07Lwr94MC2kMyRM3AxAXzlEi1bjL9s1AOKu3WILy2ZUsmd8ODMpV9sDchTwtnUo46HvNhMsXAhsw== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 4.158.2.129) smtp.rcpttodomain=redhat.com smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=arm.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dkim=[1,1,header.d=arm.com] dmarc=[1,1,header.from=arm.com]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=112ah4Lw84JS68PU9yP8+GtTiFEeYLfuQbAKiI+WVYY=; b=GOlHNanDKSflFh3VcLRdnj2l5sxsJMBqLPH59jVrNe2HcZuOBSU1/WcxvbDbkFT6m23v6PD+kBG9ESIBFJ7FFFbR7IyP2/z+EzyK9L4337KZn9CFxnzdYHQgZYUe76fz+FRGA9e68sVkgJ7SRgcAiQvTnshA7nL/kwgOposEIe8= Received: from DB8P191CA0003.EURP191.PROD.OUTLOOK.COM (2603:10a6:10:130::13) by AS4PR08MB7783.eurprd08.prod.outlook.com (2603:10a6:20b:517::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.428.11; Thu, 17 Sep 2026 15:00:58 +0000 Received: from DB5PEPF00014B8F.eurprd02.prod.outlook.com (2603:10a6:10:130:cafe::4c) by DB8P191CA0003.outlook.office365.com (2603:10a6:10:130::13) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.428.11 via Frontend Transport; Thu, 17 Sep 2026 15:00:57 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 4.158.2.129) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=arm.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 4.158.2.129 as permitted sender) receiver=protection.outlook.com; client-ip=4.158.2.129; helo=outbound-uk1.az.dlp.m.darktrace.com; pr=C Received: from outbound-uk1.az.dlp.m.darktrace.com (4.158.2.129) by DB5PEPF00014B8F.mail.protection.outlook.com (10.167.8.203) with Microsoft SMTP Server (version=TLS1_3, cipher=TLS_AES_256_GCM_SHA384) id 15.21.451.8 via Frontend Transport; Thu, 17 Sep 2026 15:00:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=Ek7ToRu2OcFQnjj96A1qNvUDASrdb2t2FG9WRy8dV5mnGYilfToYzHi879vb9s0Mst837cIftASX03JoGyTLlqxXVOSaFr1VC7NQ/sTKe06TQXXtMWLcKKU9jv+dk7RaZWIBRbmRmvrlcyrGSgaobqS6VaO+Q9PSDQaLYPBZUKWv7bKskzuqux1V3WgiwwfUH+99HAPVUqF8tc7uOifeMG486XhLilaWtIgVRlBOdSQSaE7QM7oPb/8+qlMwhYRIImhW6En3dS5tmr/3vV8gTLduRKQtJdDsZ/43r2fZCivoLKDw5ksUwK4vWUBUqD4LcLwIwFu0jBNmcvZ+WsnU6w== 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=112ah4Lw84JS68PU9yP8+GtTiFEeYLfuQbAKiI+WVYY=; b=ry0heaTmKDjlgWGjC0i9ys/O3Ro3zIJ/7cie5zCxkgyMCl+tSaPeyNib50y17eXkszxq8bdcgewMyGNExSfanDAQM7gjue6nTxjU9wupCQQ5knH3zQ0lf8iySICJiE/dTANjM8DIFzTWsOY73w8O1iL++YYIbmx2zNl9gFgYu7/aabWdBzC9pxW1heOZyD5sNYmkDG3WnVKOhtyWMw3Am407hmHFQDdMLGlDGd89xJQS4BpWOTTdbZq54aWoHwqyHNXn3DZySQnMFFHuo0D2M2F/xdKUfW9iZmfHhfZz1NGOUhiocwUaysqwYkErV/rrCevI2Qa3yg2HtNUjj4BgYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arm.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=112ah4Lw84JS68PU9yP8+GtTiFEeYLfuQbAKiI+WVYY=; b=GOlHNanDKSflFh3VcLRdnj2l5sxsJMBqLPH59jVrNe2HcZuOBSU1/WcxvbDbkFT6m23v6PD+kBG9ESIBFJ7FFFbR7IyP2/z+EzyK9L4337KZn9CFxnzdYHQgZYUe76fz+FRGA9e68sVkgJ7SRgcAiQvTnshA7nL/kwgOposEIe8= Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from AS8PR08MB8659.eurprd08.prod.outlook.com (2603:10a6:20b:563::10) by VI0PR08MB10989.eurprd08.prod.outlook.com (2603:10a6:800:24f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.406.7; Thu, 17 Sep 2026 15:00:21 +0000 Received: from AS8PR08MB8659.eurprd08.prod.outlook.com ([fe80::96bf:2de3:5eab:70ae]) by AS8PR08MB8659.eurprd08.prod.outlook.com ([fe80::96bf:2de3:5eab:70ae%5]) with mapi id 15.21.0428.008; Thu, 17 Sep 2026 15:00:21 +0000 Message-ID: <61d1cd41-986e-4aaf-87b9-ac1c46cdcca6@arm.com> Date: Thu, 17 Sep 2026 16:00:20 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 3/6] gdb: introduce helper class file_reader_t To: Andrew Burgess , gdb-patches@sourceware.org Cc: Simon Marchi , Thiago Jung Bauermann , Luis Machado , Luis Machado , Christina Joos , Kevin Buettner References: <20260825100912.514232-1-matthieu.longo@arm.com> <20260825100912.514232-4-matthieu.longo@arm.com> <87cxuldsr7.fsf@redhat.com> Content-Language: en-US From: Matthieu Longo In-Reply-To: <87cxuldsr7.fsf@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0471.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:1a8::8) To AS8PR08MB8659.eurprd08.prod.outlook.com (2603:10a6:20b:563::10) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: AS8PR08MB8659:EE_|VI0PR08MB10989:EE_|DB5PEPF00014B8F:EE_|AS4PR08MB7783:EE_ X-MS-Office365-Filtering-Correlation-Id: fb447647-a679-493e-0f05-08df14cc7ac4 x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; ARA:13230040|366016|1800799024|376014|23010399003|5023799004|56012099006|6133799003|11063799006|22082099003|4143699003|10067099003|18002099003; X-Microsoft-Antispam-Message-Info-Original: h63NxhPiiZFCqIFua8H+OiG9DonA+CryoWhMrnUf1woBWWP9ZhOPvWnPsf5tJXNnDCCIkCZNI1R9hw0lxqcSMTgaJDNeAhKrnT4msLXjm/nG6QqkMF6P2QrG51HQ38AkBfu7Ln6V7IiLsYlo4aQKgObQ+qVg1pB5VGn8w7ptqfhm4DHDeEKH4kcLxrnvWm/EZ0n1hMSGrM2TFm4YSV7WHNVKnCRxQkYgqWO7vYWPrNxBE+G34nrahLsXhD2PkRUmx4J+4+XBC4hPfpdudOnhyvQ/g/CxqhoVY1nYSEcUEwtQ+7qnDiPTAXgZ5r/Uy5t2Pp0SDwFhhLyHT/NBC/T/DkNjeDrLP5QbquVypf9geGdKsZpz2t0EFSeyMVLCiVXb0CVTf32qHDntShgGspv8uVAPE+q1LVFEkCrQc6f54uhgixSQfShsVNH0o09xaCyi3smpRfpKEco8NO9UdgCxf/KeBWYH/szbcOFo5HeAP8PrC2Odoi9mRv7lGv6Rrv0AgftPwkENOfuOqhXYuqyIQE9sK2wGYhjqTuc9Os4kn0fDZlp/qNLGFEJwjlatWOBTUJO4GTP8jYSFCj0lDkY2x8trcTk+XrF9BWCeO9/lzIRY7TJiI6gq9a0326d4bV1Xsukmdm5WNhv/qeDI31AzGhQ7RVFleqReAETZ5SIxhb4= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR08MB8659.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230040)(366016)(1800799024)(376014)(23010399003)(5023799004)(56012099006)(6133799003)(11063799006)(22082099003)(4143699003)(10067099003)(18002099003); DIR:OUT; SFP:1101; X-Exchange-RoutingPolicyChecked: gWNsjgDbQmT/g7slaWQ1S0GQRH6zOQ22Z/xxjFJQXvz1QUMDNW185vLDioqfdam3TDNy73OcqagsSjSbJMjXVZwQLu2R1W5WUAUePQcSRnqTOCerpXBiaWo3UXVzQ7ZWAEXJ4sFzsdV6arHk5/zC42WUxcIJb7bSg/oeVLKXw3iBGtrqKQjwbRP6TrvTNZtXXgnquvWXR7I0A2tso2f+P2ZoMfZT49egzqScCq36d5BtdjgMgeHTC9fc+x3nBz2SKu1IiaAanGCQJ3rzunZfXy9RltO9NrDExHRmDpwOBKf07FbQGLK+q21AKfIYltJ99WKASt5+fdDvq5l7e0BXLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI0PR08MB10989 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5PEPF00014B8F.eurprd02.prod.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 29c06692-63c1-44dd-c081-08df14cc650a X-Microsoft-Antispam: BCL:0; ARA:13230040|14060799003|23010399003|35042699022|82310400026|36860700016|376014|1800799024|6133799003|22082099003|18002099003|4143699003|5023799004|11063799006|56012099006|10067099003; X-Microsoft-Antispam-Message-Info: uRC3ambwiPBlsNeCKpK6xOSNPuUKfkmbqPWoe9oOqj23Imf7vWgLyxTgVYv0jhsSEwb1LkpK9VcN/j5aotluTO7xu6SEe1V06eenzpf7yZSyqUMpQ5iocw3VMaVCSgJ4mzOpP90jPoHDVybUDwkWYYB5Te7Nluhu+UOv1Nk66lykep2xlms9lTR4FMdzWNnv6k/qGc+ZE/2T3YRcpiMCIGiMnRwo4lYx8DTBgqB64kkSVApgPZ0gqCpdHj2a7qAzCi0oyGo5qsaWW+ELs8KwxczyFJXQABwfpLuVMQVGCFfdFUN1FYOmHzFhuBdOaSwHu9WMZmccYJxqcRypOy/QRTjWz2Da3vazNt/Mv2cpfrE/8BpclC2xCEO0OUWd+2XrLEfaL9RURu77Ef4eNaQXP3h6OzYEKETtywSFhMTFbxmBlRdokwlyrwKrYaz3agMbpgjeWm0Cvx/R+Xe4Nw5NZRkm+GPvg2+KSbQ7afYYrgtPm2nzm7DmI8W6N1U2zHTSq1jwXQnJgTc0nMYBsi2w4gyQcwPk7MeTxh6YcQ5Xd3LXKtugbiHkfmrXCzRPrZlcaf78Hw1P56ZOMBmTUUqUbawJZT957YQ/RcCqL7GElUPwcUOzIcYKkLiIozT88F9jkgGDt/a/nHKusqiV/DeazX1ibzPtda7oHm+f+Fce6O6jPNT7tl1A5CwewOwLiM+TiHTaeKAZx/eqCzhTPgGUaQ== X-Forefront-Antispam-Report: CIP:4.158.2.129; CTRY:GB; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:outbound-uk1.az.dlp.m.darktrace.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230040)(14060799003)(23010399003)(35042699022)(82310400026)(36860700016)(376014)(1800799024)(6133799003)(22082099003)(18002099003)(4143699003)(5023799004)(11063799006)(56012099006)(10067099003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: D291VvImv9SNh295Zs9UR936lH39CzeB5B2VSauY4GiS0f1m+Xaz78Kza2dA86CVc4imLVXFVwR7nTj55fpvJTG2YLg+GjcLMR3+65kE9wv4604MP0k5plCR9EW938BvO2hIFlmpy0qW5iD5/zHJRbY3FGx67UQykGMDjQdoU8UEWKoihv7bbyhvXFQwbiR++78gRm8B6ttnDl/6WOZi6UC7Bpj3QEg125qOXIRls5bvPEF2UAOCrUn1L13JLvK80ZNa4WVVndQQRTvE6cDx+aPMvGl22Zxgj2pnmC/4PCb4b/kmLG1WSpTqLu6/qPWLb65esgFqUoAD7xQIWx3ZRB8/bLje32UakCOfw1gRqkXh+EV9P+T8IlzTE+CX69CP+Vg5GpIdxHPG30QCWK/66DMMhiQa9NLMK7MkJMKlAMkinRuJ+GU2rAF7WCfnO+Ho X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Sep 2026 15:00:57.4381 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb447647-a679-493e-0f05-08df14cc7ac4 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[4.158.2.129]; Helo=[outbound-uk1.az.dlp.m.darktrace.com] X-MS-Exchange-CrossTenant-AuthSource: DB5PEPF00014B8F.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4PR08MB7783 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 On 10/09/2026 16:35, Andrew Burgess wrote: > Matthieu Longo writes: > >> Wrap all the boilerplate code required to read a file in a new helper >> class: file_reader_t. The class owns the file contents together with >> the file path, and provides convenient accessors for the data, size and >> typed views. It supports both null-terminated text files and binary files. >> >> This helper eliminates repeated calls to target_fileio_read_stralloc >> and target_fileio_read_alloc, remove explicit memory management with > > s/remove/removes/ > Fixed. >> gdb::unique_xmalloc_ptr, and simplifies the casting logic when working >> with binary data. >> >> The patch converts some of the existing Linux, AMD64, and SPARC code that >> reads files from /proc to use file_reader_t. As a side effect, >> amd64_linux_lam_untag_mask and linux_process_address_in_memtag_page >> may now return earlier in case the file is empty. >> >> Reviewed-By: Thiago Jung Bauermann >> Reviewed-By: Christina Joos >> --- >> gdb/amd64-linux-tdep.c | 12 ++-- >> gdb/linux-tdep.c | 122 ++++++++++++++++++----------------------- >> gdb/sparc64-tdep.c | 15 +++-- >> gdb/target.h | 78 ++++++++++++++++++++++++++ >> 4 files changed, 143 insertions(+), 84 deletions(-) >> >> diff --git a/gdb/amd64-linux-tdep.c b/gdb/amd64-linux-tdep.c >> index 9b23db72bbe..52f16c953d1 100644 >> --- a/gdb/amd64-linux-tdep.c >> +++ b/gdb/amd64-linux-tdep.c >> @@ -1848,14 +1848,11 @@ amd64_linux_lam_untag_mask () >> if (inf->fake_pid_p) >> return DEFAULT_TAG_MASK; >> >> - const std::string filename = string_printf ("/proc/%d/status", inf->pid); >> - gdb::unique_xmalloc_ptr status_file >> - = target_fileio_read_stralloc (nullptr, filename.c_str ()); >> - >> - if (status_file == nullptr) >> + file_reader_t proc_status (string_printf ("/proc/%d/status", inf->pid)); >> + if (!proc_status) >> return DEFAULT_TAG_MASK; >> >> - std::string_view status_file_view (status_file.get ()); >> + std::string_view status_file_view (proc_status.data ()); >> constexpr std::string_view untag_mask_str = "untag_mask:\t"; >> const size_t found = status_file_view.find (untag_mask_str); >> if (found != std::string::npos) >> @@ -1867,7 +1864,8 @@ amd64_linux_lam_untag_mask () >> unsigned long long result = std::strtoul (start, &endptr, 0); >> if (errno != 0 || endptr == start) >> error (_("Failed to parse untag_mask from file %ps."), >> - styled_string (file_name_style.style (), filename.c_str ())); >> + styled_string (file_name_style.style (), >> + proc_status.c_filepath ())); >> >> return result; >> } >> diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c >> index 588984a1ca4..84614bc91a0 100644 >> --- a/gdb/linux-tdep.c >> +++ b/gdb/linux-tdep.c >> @@ -1551,7 +1551,7 @@ parse_smaps_key_value (const char *keyword, const char *line, >> DATA is the contents of the smaps file. The parsed contents are stored >> into the SMAPS vector. */ >> >> -static std::vector >> +static std::vector > > Throughout this patch there's a bunch of places where you've done > nothing but delete the 'struct' prefix. It's OK to do this in code that > you're touching anyway as part of this patch, but any, like this, that > are in code that you'd not otherwise touch, are unrelated changes and > should be moved into a separate patch. > > I think you should either drop these, or have a first patch which does a > "remove some struct prefixes" cleanup, your choice. > Moved to a separate patch. >> @@ -2346,27 +2343,24 @@ linux_fill_prpsinfo (struct elf_internal_linux_prpsinfo *p) >> p->pr_pid = ptid.pid (); >> >> /* Copying the program name. Only the basename matters. */ >> - basename = lbasename (fname.get ()); >> + basename = lbasename (cmdline.data ()); >> strncpy (p->pr_fname, basename, sizeof (p->pr_fname) - 1); >> p->pr_fname[sizeof (p->pr_fname) - 1] = '\0'; >> >> const std::string &infargs = current_inferior ()->args (); >> >> /* The arguments of the program. */ >> - std::string psargs = fname.get (); >> + std::string psargs = cmdline.data (); >> if (!infargs.empty ()) >> psargs += ' ' + infargs; >> >> strncpy (p->pr_psargs, psargs.c_str (), sizeof (p->pr_psargs) - 1); >> p->pr_psargs[sizeof (p->pr_psargs) - 1] = '\0'; >> >> - xsnprintf (filename, sizeof (filename), "/proc/%ld/stat", ptid.lwp ()); >> - /* The contents of `/proc/PID/stat'. */ >> - gdb::unique_xmalloc_ptr proc_stat_contents >> - = target_fileio_read_stralloc (NULL, filename); >> - char *proc_stat = proc_stat_contents.get (); >> - >> - if (proc_stat == NULL || *proc_stat == '\0') >> + file_reader_t stat_freader >> + (string_printf ("/proc/%ld/stat", ptid.lwp ())); >> + const char *proc_stat = stat_freader.data (); >> + if (!stat_freader || *proc_stat == '\0') > > We access the data here before checking if the read was successful. > This works fine, but doesn't seem ideal. Later on I suggest that maybe > file_reader_t::data should assert that we're no in the error state, and > this is what I was looking at when I started thinking about that. > I added the assert inside '.data()'. > If you really think we should support reading data when in an error > state, then the data method should document what the return value is > when the file_reader_t is in the error state. > and changed the code to call .data() after having checked for errors: diff --git a/gdb/linux-tdep.c b/gdb/linux-tdep.c index ff183ade578..1a675281864 100644 --- a/gdb/linux-tdep.c +++ b/gdb/linux-tdep.c @@ -2358,8 +2358,9 @@ linux_fill_prpsinfo (struct elf_internal_linux_prpsinfo *p) target_file_reader stat_freader (string_printf ("/proc/%ld/stat", ptid.lwp ())); - const char *proc_stat = stat_freader.data (); - if (!stat_freader || *proc_stat == '\0') + const char *proc_stat = nullptr; + if (stat_freader.empty_or_error () + || *(proc_stat = stat_freader.data ()) == '\0') { /* Despite being unable to read more information about the process, we return true here because at least we have its @@ -2433,8 +2434,9 @@ linux_fill_prpsinfo (struct elf_internal_linux_prpsinfo *p) contents of the `/proc/PID/status' file. */ target_file_reader status_freader (string_printf ("/proc/%ld/status", ptid.lwp ())); - char *proc_status = status_freader.data (); - if (!status_freader || *proc_status == '\0') + char *proc_status = nullptr; + if (status_freader.empty_or_error () + || *(proc_status = status_freader.data ()) == '\0') { /* Returning true since we already have a bunch of information. */ return true; I hope that this looks better. > >> diff --git a/gdb/target.h b/gdb/target.h >> index 819279c08fc..017918b6582 100644 >> --- a/gdb/target.h >> +++ b/gdb/target.h >> @@ -2341,6 +2341,84 @@ extern LONGEST target_fileio_read_alloc (struct inferior *inf, >> extern gdb::unique_xmalloc_ptr target_fileio_read_stralloc >> (struct inferior *inf, const char *filename, LONGEST *len = nullptr); >> >> +/* Helper class for reading the content of a file on the target. */ >> +template >> +class file_reader_t > > I'm pretty sure that types ending with _t are reserved by ... some > spec. We should avoid this and ideally, pick a name that better > describes what the class does, e.g. target_file_reader. > Renamed file_reader_t to target_file_reader. >> +{ >> + /* The filepath of the file being read. */ >> + std::string m_filepath; > > The ship has mostly sailed already, but "path" should be used for lists > of locations, like the $PATH variable. It would be better to just use > filename, m_filename, etc. I am fully aware that 'path' is used > throughout GDB in place of filename, but we might as well avoid adding > another here. > > This should be fixed throughout this class. > Renamed to m_path, and filepath() and c_filepath() to path() and c_path() respectively. >> + /* Smart pointer to the data. */ >> + gdb::unique_xmalloc_ptr m_data; >> + /* Number of bytes read. */ >> + LONGEST m_size; > > GDB style usually puts a space between member variables, e.g.: > > /* The filepath of the file being read. */ > std::string m_filepath; > > /* Smart pointer to the data. */ > gdb::unique_xmalloc_ptr m_data; > > /* Number of bytes read. */ > LONGEST m_size; > Fixed. >> + >> +public: >> + file_reader_t (const std::string &filepath) >> + : m_filepath (filepath) >> + , m_size (0) >> + { >> + if constexpr (std::is_same_v) >> + m_data = target_fileio_read_stralloc (nullptr, m_filepath.c_str (), >> + &m_size); >> + else >> + { >> + gdb_byte *buf = nullptr; >> + m_size = target_fileio_read_alloc (nullptr, m_filepath.c_str (), &buf); >> + m_data = gdb::unique_xmalloc_ptr (reinterpret_cast(buf)); >> + } >> + } > > There's a bug hiding in here when T is not 'char'. If the file being > read is empty then target_fileio_read_alloc returns 0 but leaves *BUF > unchanged, i.e. as nullptr. > > Given that, despite successfully reading the empty file, empty() will > return false and error() will return true. > Thanks for pointing this out. I completely missed it. I added this comment in the constructor: /* Read the content of the file associated to PATH from the filesystem as seen by INF. If INF is NULL, use the filesystem seen by the debugger (GDB or, for remote targets, the remote stub). */ target_file_reader (const std::string &path, struct inferior *inf = nullptr) : m_path (path) , m_size (0) { /* The interface of target_fileio_read_stralloc and target_fileio_read_alloc may appear inconsistent, but the difference is intentional. On error, both functions return nullptr and set the size to a negative value. For a successful read of an empty file, however, the size is zero and their return values differ: - target_fileio_read_stralloc returns an allocated empty string rather than nullptr. The allocation contains the terminating '\0'. - target_fileio_read_alloc simply returns nullptr. Hence, an assert in .data(), .view () and .cast_view () enforcing no error but a valid buffer address. gdb_assert (!error () && m_data != nullptr); */ if constexpr (std::is_same_v) m_data = target_fileio_read_stralloc (inf, m_path.c_str (), &m_size); else { gdb_byte *buf = nullptr; m_size = target_fileio_read_alloc (inf, m_path.c_str (), &buf); m_data = gdb::unique_xmalloc_ptr (reinterpret_cast(buf)); } } > Also, given this is being written as a general helper class, it might be > a good idea to define how the inferior is passed in, rather than leaving > that for future users to do. > Change the constructor to: /* Read the content of the file associated to PATH from the filesystem as seen by INF. If INF is NULL, use the filesystem seen by the debugger (GDB or, for remote targets, the remote stub). */ target_file_reader (const std::string &path, struct inferior *inf = nullptr) >> + >> + file_reader_t (file_reader_t &&) = default; >> + file_reader_t &operator= (file_reader_t &&) = default; >> + >> + DISABLE_COPY_AND_ASSIGN (file_reader_t); >> + >> + /* Return true if the file was read successfully but contained no data. */ >> + bool empty () const noexcept >> + { return m_data != nullptr && m_size == 0; } >> + >> + /* Return true if the file could not be read. */ >> + bool error () const noexcept >> + { return m_data == nullptr || m_size < 0; } >> + >> + /* Return true if the file was read successfully and is non-empty. */ >> + explicit operator bool () const noexcept >> + { return !(error () || empty ()); } > > I'm really not a fan of this API. Consider this code from earlier in > this patch: > > file_reader_t proc_status (string_printf ("/proc/%d/status", inf->pid)); > if (!proc_status) > return DEFAULT_TAG_MASK; > > I don't think it's obvious that !proc_status means error or empty. I > think a much less error prone API would be to just add a new member > function: > > bool empty_or_error () const noexcept > { return this->empty () || this->error (); } > > And then use that. It's more typing for sure, but it's also crystal > clear what's going on. > Added and adapted the code using it. >> + >> + /* Return a pointer to the data. */ >> + T *data () const noexcept >> + { return m_data.get (); } > > Might be a good idea to assert that we're not in the error state. > Fixed, but not only checking for '!.error ()' but also 'm_data != nullptr'. >> + >> + /* Return the number of bytes read. */ >> + LONGEST size () const noexcept >> + { >> + /* For char buffers, size() corresponds to the size of the read data. Some >> + null-terminator characters are possibly scattered throughout the data. >> + Consequently, strlen() might not reflect the actual size. */ >> + return m_size; >> + } > > Again, maybe assert that we're not in the error state. I think there's > only one user of this right now, and it already checks for errors before > calling size. > Fixed, but only checking for '!.error ()'. >> + >> + /* Return a span of the data. */ >> + gdb::array_view view () const noexcept >> + { return gdb::array_view (m_data.get (), size ()); } >> + >> + /* Return a span of the data, reinterpreted as U objects. */ >> + template >> + gdb::array_view cast_view () const noexcept >> + { >> + return gdb::array_view (reinterpret_cast (m_data.get ()), >> + size () * sizeof (T) / sizeof (U)); >> + } > > It would be a good idea to say in the comment what happens if the file > size is not a multiple of 'sizeof (U)'. Or do we even want to support > this case? I added some asserts and stated clearly the requirements on U. /* Return a view of the data, reinterpreted as objects of type U. The size of the underlying storage must be an exact multiple of sizeof (U), and the storage must be suitably aligned for U. */ template gdb::array_view cast_view () const noexcept { gdb_assert (!error () && m_data != nullptr); size_t nbytes = size () * sizeof (T); /* The number of bytes must be a multiple of sizeof(U). Do not silently discard trailing bytes. */ gdb_assert (nbytes % sizeof (U) == 0); /* The underlying storage must satisfy U's alignment requirement. */ gdb_assert (reinterpret_cast (m_data.get ()) % alignof (U) == 0); return gdb::array_view (reinterpret_cast (m_data.get ()), nbytes / sizeof (U)); } > > Thanks, > Andrew Thanks for the valuable review, Matthieu