From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2087.outbound.protection.outlook.com [40.107.21.87]) by sourceware.org (Postfix) with ESMTPS id C92D338582A2 for ; Mon, 11 Jul 2022 10:13:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C92D338582A2 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=LN6FeVv/J/QNYJw8hxy5/063AYW5Br9SJtGCijtLtfP08jQxdMDMbuMjiGIq/RnoNlrJWrDNAGqHk6qlWxJLlIEzt6Rn2zO+0Q6KvQ5rqgWGoO6ER3A0a3PXjbDi9Kq6rhM8tvYAPmO945HAiwbRRdYPlRh9KOCT7uNQGJJZlEVTSkrgdrtYlvpEZykKFAs7e9jcuEb2z3W8uVBQkJylEglEwzNM4jaFgS069vycQDnvwLkB8+nMWkaJI+Dg/vEMF8UARiPsPEK34OsFYuDB/Y0vsbIlLdY4Gqx1HOWMPzz8hOF+7Q3lnZ/hZ6GWCPpxc8uKQlW29LzjgHBuMUSlOw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=5mLWibKXjlpRlqXd6gl1siSWNrVVVwd/15J9CNk06zI=; b=Nsgb8N3vaFFex9d2YwAKsegM/SZ9nlBIsg8/GFp7rW6BGf2kdkwAYorU002wTP8cFKo7dS7e9jWu+FbnwX5AmevoTeoZ6fCh6WsJttHCLeXgp2KQ4AA2bdcuGO+1cUyFx9mr8g03ZA8hTikCq38ULIXDZnX7i+999OBr+zFcHDjeul8O6sZbiJqJRJpMMO7QQXGCyfwnYOixfJh20wxhGi3Wq2e8Jad9XlxsPzTdKyFQyYW2b+rPUxJCroEpzFi6cUohLKrhDF8KALD9Zs9CssxHst8ahTdvf+W70iDXTxMbUDf6LSgmKu/dK7swX6ZGilE/hBn8FBqYDlx5iug18w== ARC-Authentication-Results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=sourceware.org 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=armh.onmicrosoft.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]) Received: from AS9PR06CA0135.eurprd06.prod.outlook.com (2603:10a6:20b:467::22) by AM9PR08MB6984.eurprd08.prod.outlook.com (2603:10a6:20b:417::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.15; Mon, 11 Jul 2022 10:13:55 +0000 Received: from AM5EUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:467:cafe::79) by AS9PR06CA0135.outlook.office365.com (2603:10a6:20b:467::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.20 via Frontend Transport; Mon, 11 Jul 2022 10:13:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;dmarc=pass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; pr=C Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT012.mail.protection.outlook.com (10.152.16.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.15 via Frontend Transport; Mon, 11 Jul 2022 10:13:55 +0000 Received: ("Tessian outbound 6f9e7ef31fa8:v122"); Mon, 11 Jul 2022 10:13:55 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b6a626ce3dbc987c X-CR-MTA-TID: 64aa7808 Received: from f4c1c78670f6.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id CF2EFFB0-7026-46F7-80CC-9F9B9B0BBDB9.1; Mon, 11 Jul 2022 10:13:49 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f4c1c78670f6.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 11 Jul 2022 10:13:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OUUuSxcTqQbV935OJ4JF1IgAMGpFviLMG+z8MxkGeYqYN/JSTfF8HVPa75BY+i1op+e5fSYEAWOlv1aq8L217Iz9k47CR8I8qd4RQbVOEHkmzD+Ong6gTK/5Z5WDh5913kJ4rv676NrJ7C5aPEMPqgfm028xOQl5rEZ0qnKWAprCdKBW6R/SmGi4wuLgXGKwWBca44U5Gi/JtYZVSH9Sl6tVRHYJHrBLO6DWoeI3dxf/LCj4U6cFsGnf/RxnAbBZBddAQMbwb+C4iVfSpzmMOhiAvSGGoZfsUDb8cSlBMv28cRTd9dkyIK0rhX2Qghn2kweC6oFdowpPs2bfIdF+qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; 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=5mLWibKXjlpRlqXd6gl1siSWNrVVVwd/15J9CNk06zI=; b=dBoPqo235TC3qU2qZU3mL/6GGuHLjDAtjOmGbVKvgt7UAimsChuR62X0cjpR1ZiWZAfojyI2aF3kZ14xKLDR3hr399SawfwF9rcbmrjtNLLRR+H74Lfz2A2I48LslKdnu4afxOTzEYRy3eGcMhhNYzDflJbY7R1dspbT2ilgTn24hmB/hA2cwFW3FOThbph2kW4k2Ptm5VecGgAUchc3uvEfpFkepqb6+l+dZjl6jeHaADOoTESWC7Nkg0z+3w/dSDtNKPdRgXnAxqhGv7CWuvAFuqmCNZ6Qd2lzNc6f3E4N+FqSIJgVXYeiAe1U39U7AnBQr3b3Ixm+vi7/CQ/v1g== 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 Authentication-Results-Original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; Received: from VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) by AM6PR08MB3671.eurprd08.prod.outlook.com (2603:10a6:20b:46::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.25; Mon, 11 Jul 2022 10:13:46 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::1cda:8ca1:6353:572c]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::1cda:8ca1:6353:572c%4]) with mapi id 15.20.5417.026; Mon, 11 Jul 2022 10:13:46 +0000 Message-ID: <6d32ac14-992f-fe6c-b09e-adfecb214dba@arm.com> Date: Mon, 11 Jul 2022 11:13:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH, v4] [AArch64] MTE corefile support Content-Language: en-US To: Pedro Alves , gdb-patches@sourceware.org References: <20220331140343.9047-1-luis.machado@arm.com> <20220503215632.914608-1-luis.machado@arm.com> From: Luis Machado In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: LO4P123CA0367.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18e::12) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 462fb6ce-8723-403e-7c91-08da63261003 X-MS-TrafficTypeDiagnostic: AM6PR08MB3671:EE_|AM5EUR03FT012:EE_|AM9PR08MB6984:EE_ x-checkrecipientrouted: true NoDisclaimer: true X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: gFVLVFEsTwVVqTek9f0dyCe9nNrPhH+1ximsYqhG6APrey50cYyCX7V5vYPe1A41ouJ6t2HWOi8lfUIBw52cv5sDkDJImSN80Q1PMqT6Wo4w6iaZvMHPAjJBIFHlqcmclaeVT8N1oB32gwE/jvP1r0xb0rX2Z5tOgsfNi7JZiSnNchA4whY61TrtNUZHT7YrCgdPr+Klk7eTL+rRiXYBOKW2kSzdFyFWx9s8VzVZgKqmuotE/IAnPjJ8t95ep6CVjdSNGiKjmNVuecoj4kwJtzPKkuwVOy/Hsq9ccMpwdyNLxI2n6U6A9z41vssljwW9FboBxexGaShGthIW+OK3mXIrDggLBGdcxpcStMPeTm5Luhv2lBEGklc78KIbH4FHoN3T/ma7JWvnwycXF6Yx1sT9Aqxb/EB8J8r9IIJntFM9Nsx8Y2FzF/PtZjT9j9sNgrdfnKjYY+80vJptDr6Hcaykm2K2bhbuKx4nwpVaAEoSu1+AkR45m1bzXPjfXhQGLO/S/0jGSDCPphVHs4nTgltUSuRcQMfnyjQZGf4MNjrQ3/TQkZJsuUawrGuOYbhgT7okuaL0wb0p9FLB+J9FF0ygftOh0dO8jcorbYARN6VwxJUL8scm0MAgfUNWJg+0ITI6MDG+t7N51UjiNNk92UyVJ4pUAnuoPlNRmQNMoSfQKDquFxN2BECCZ/rQFsd1LTzKLBq2l1Bh39HVBPdGmZ9Du5ooCsegoH6SrgplveAgH021hdKIChbRNq1lyPJtpJwjADAnwilUuhmV4RNh17/8TotZT62sEyWe5J5T470IMKelYxSue7ZtJIlly5ICznsu3yyL39w4haRfsq79P6CGB6P0RyyHE0sWBB0RkW4= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR08MB3919.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(376002)(136003)(396003)(346002)(366004)(39860400002)(6512007)(8676002)(66946007)(8936002)(86362001)(6506007)(66476007)(41300700001)(186003)(66556008)(31696002)(53546011)(26005)(2616005)(36756003)(6486002)(478600001)(31686004)(38100700002)(2906002)(83380400001)(44832011)(5660300002)(316002)(30864003)(2004002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3671 Original-Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: a6089edb-bc24-43df-889d-08da63260ac0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AkmMG/FAAznUsWLF5L5y+D9fAUOZdfQhTX8z1cY71FAxiIMPo8VpX+zcEhYfqAOZM+31c9VKiqx9tL/y1x+IvzWdP2sfIcFg+fg7ShZadjX//7DidXvfGbIifb0GaX2oxYe4fxpp/vIPnOp5OS0tjUPyiNDSUri1G2TflzVcNfRwUVWVjqYRLAZ3AY7UBndCkpBkWjb0kRDZIdbdwaaRYTQ5b7U3E2FsPvdZxoAQd9Y76pf4PzhbKjBJIp3iM0OqMJ+eeK2DsK1fEw/XGp01yLS5A+MjVnHzgEK8CliZuPhjQBzq6kx1RW4rSL4qNDvcJPKZq/Xuk6FRdFijEYeKnAZRUXDSRWC1iqT6RrMRaNb3r6UEgY7+lqDTSDQuPgjBYftLK1PIcX0zGlZRld57Dr437ae54nIJVBcMj7Xk7O82jT8r3lpufCZxDaA9HfusmHqyXMZLpyuvB/jCySCvFkHBqpCWZIk/lNKGaqZsqpkKr9gDSaJ/sAh4wJZyPi7mJsmAWbGWEU6VMG85b2xrm5Y9BKaP1tGDmdsGaBk/K5jgNPfm4n1H10/saCpcssFfHHlJ+f3TPTrwjxRPm6Ii3NKYBnMQNmAs2f3ylEaTpwQDbhvQDrUyIDJ0I0U7aE21hDMf2jMG09pyoBqQeSN/qcSAhRvePVhOzXw53/lzGNbYJXi14s8vej9p8S4heUok9M2N8Xh/6nAH+S/qK0LTiQOynWH5og/KYXoRCpJZ7YucIIH++t5R4ACpzXRZTVmYyQc7MBAxJARt7Ds3K7TPZAlYDs21r7tf6jeyrk5TF8s9dVxrXg1GPm19xTM4QU61sN5AK4M5kHWp30T4TxryaepHfg+6F62VTb02nbu2X7+t6bqMDYOGLTYcbCboAWJ7 X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFS:(13230016)(4636009)(396003)(39860400002)(376002)(346002)(136003)(40470700004)(36840700001)(46966006)(44832011)(31686004)(5660300002)(30864003)(36860700001)(70206006)(6512007)(316002)(40480700001)(2616005)(70586007)(186003)(53546011)(2906002)(6506007)(41300700001)(26005)(6486002)(82310400005)(478600001)(83380400001)(86362001)(47076005)(40460700003)(31696002)(356005)(81166007)(336012)(8936002)(8676002)(36756003)(82740400003)(2004002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jul 2022 10:13:55.4136 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 462fb6ce-8723-403e-7c91-08da63261003 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT012.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR08MB6984 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, GIT_PATCH_0, KAM_DMARC_NONE, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 10:14:02 -0000 Hi, On 6/27/22 15:51, Pedro Alves wrote: > Hi Luis, > > On 2022-05-03 22:56, Luis Machado via Gdb-patches wrote: >> v4: >> >> - Updated documentation (added cross-references). >> - Updated the segment name from PT_ARM_MEMTAG_MTE to >> PT_AARCH64_MEMTAG_MTE. >> >> v3: >> >> - Updated NEWS and documentation to be more thorough. >> >> v2: >> >> - Rework memory tag section handling to use generic section fields. >> >> -- >> >> Teach GDB how to dump memory tags for AArch64 when using the gcore command >> and how to read memory tag data back from a core file generated by GDB >> (via gcore) or by the Linux kernel. >> >> The format is documented in the Linux Kernel documentation [1]. >> >> Each tagged memory range (listed in /proc//smaps) gets dumped to its >> own PT_AARCH64_MEMTAG_MTE segment. > > ... > >> A section named ".memtag" is created for each >> of those segments when reading the core file back. > > It's "memtag", not ".memtag", AFAICT. > Yep. I had fixed this already in a local version for an upcoming v5. >> +/* AArch64 Linux implementation of the gdbarch_create_memtag_section hook. */ >> + >> +static asection * >> +aarch64_linux_create_memtag_section (struct gdbarch *gdbarch, bfd *obfd, >> + CORE_ADDR address, size_t size) >> +{ >> + gdb_assert (obfd != nullptr); >> + gdb_assert (size > 0); >> + >> + /* Create the section and associated program header. */ >> + asection *mte_section = bfd_make_section_anyway (obfd, "memtag"); >> + >> + if (mte_section == nullptr) >> + return nullptr; >> + >> + bfd_set_section_vma (mte_section, address); >> + /* The size of the memory range covered by the memory tags. We reuse the >> + section's rawsize field for this purpose. */ >> + mte_section->rawsize = size; >> + /* Tags are stored packed as 2 tags per byte. */ >> + bfd_set_section_size (mte_section, (size / AARCH64_MTE_GRANULE_SIZE) / 2); > > Shouldn't the /2 division round up, rather than down, to account for odd number > of tags? I.e., this: > > bfd_set_section_size (mte_section, (size / AARCH64_MTE_GRANULE_SIZE + 1) / 2); > Indeed. I think we just got away with it because we can only allocate maps sized in multiples of the page size. So that will guarantee we will also have an exact division here. It is not quite correct for an odd number of tag granules. I'll fix this. >> + /* Make sure the section's flags has SEC_HAS_CONTENTS, otherwise BFD will >> + refuse to write data to this section. */ >> + bfd_set_section_flags (mte_section, SEC_HAS_CONTENTS); > > How about using bfd_make_section_anyway_with_flags further above? > Should work fine. Done now. >> + >> + /* Store program header information. */ >> + bfd_record_phdr (obfd, PT_AARCH64_MEMTAG_MTE, 1, 0, 0, 0, 0, 0, 1, >> + &mte_section); >> + >> + return mte_section; >> +} >> + > > >> + >> +/* AArch64 Linux implementation of the gdbarch_fill_memtag_section hook. */ >> + >> +static bool >> +aarch64_linux_fill_memtag_section (struct gdbarch *gdbarch, asection *osec) >> +{ >> + /* We only handle MTE tags for now. */ >> + >> + size_t segment_size = osec->rawsize; >> + CORE_ADDR start_address = bfd_section_vma (osec); >> + CORE_ADDR end_address = start_address + segment_size; >> + >> + /* Figure out how many tags we need to store in this memory range. */ >> + size_t granules = aarch64_mte_get_tag_granules (start_address, segment_size, >> + AARCH64_MTE_GRANULE_SIZE); >> + >> + /* If there are no tag granules to fetch, just return. */ >> + if (granules == 0) >> + return true; >> + >> + CORE_ADDR address = start_address; >> + >> + /* Vector of tags. */ >> + gdb::byte_vector tags; >> + >> + while (granules > 0) >> + { >> + /* Transfer tags in chunks. */ >> + gdb::byte_vector tags_read; >> + size_t xfer_len >> + = (granules >= MAX_TAGS_TO_TRANSFER)? >> + MAX_TAGS_TO_TRANSFER * AARCH64_MTE_GRANULE_SIZE : >> + granules * AARCH64_MTE_GRANULE_SIZE; > > '?' and ':' go on the next line, like other operators. Wrap expression in > parens for proper alignment, per GNU standards. So: > > = ((granules >= MAX_TAGS_TO_TRANSFER) > ? MAX_TAGS_TO_TRANSFER * AARCH64_MTE_GRANULE_SIZE > : granules * AARCH64_MTE_GRANULE_SIZE); > > (note how you can read "?" as "then" and ":" as "else", this way.) > Fixed the formatting now. Thanks. >> + >> + if (!target_fetch_memtags (address, xfer_len, tags_read, >> + static_cast (memtag_type::allocation))) >> + { >> + warning (_("Failed to read MTE tags from memory range [%s,%s)."), >> + phex_nz (start_address, sizeof (start_address)), >> + phex_nz (end_address, sizeof (end_address))); >> + return false; >> + } >> + >> + /* Transfer over the tags that have been read. */ >> + tags.insert (tags.end (), tags_read.begin (), tags_read.end ()); > > (Just a passing comment, feel free to ignore: If target_fetch_memtags were adjusted to > append to the buffer instead of clearing it, you could pass "tags" directly to > target_fetch_memtags and get rid of this copying.) > I think it is a reasonable idea. I'm not keen on chaging it up at this point, but that would be a good improvement. I just need to make sure the callers all cleanup the tags vector before passing it onwards to the functions. >> + >> + /* Adjust the remaining granules and starting address. */ >> + granules -= tags_read.size (); >> + address += tags_read.size () * AARCH64_MTE_GRANULE_SIZE; >> + } >> + >> + /* Pack the MTE tag bits. */ >> + aarch64_mte_pack_tags (tags); >> + >> + if (!bfd_set_section_contents (osec->owner, osec, tags.data (), >> + 0, tags.size ())) >> + { >> + warning (_("Failed to write %s bytes of corefile memory " >> + "tag content (%s)."), >> + pulongest (tags.size ()), >> + bfd_errmsg (bfd_get_error ())); >> + } >> + return true; >> +} >> + > >> + >> +/* See arch/aarch64-mte-linux.h */ >> + >> size_t >> aarch64_mte_get_tag_granules (CORE_ADDR addr, size_t len, size_t granule_size) >> { >> diff --git a/gdb/arch/aarch64-mte-linux.h b/gdb/arch/aarch64-mte-linux.h >> index d158926feff..8a145b447aa 100644 >> --- a/gdb/arch/aarch64-mte-linux.h >> +++ b/gdb/arch/aarch64-mte-linux.h >> @@ -32,6 +32,7 @@ >> >> /* We have one tag per 16 bytes of memory. */ >> #define AARCH64_MTE_GRANULE_SIZE 16 >> +#define AARCH64_MTE_TAG_BIT_SIZE 4 >> #define AARCH64_MTE_LOGICAL_TAG_START_BIT 56 >> #define AARCH64_MTE_LOGICAL_MAX_VALUE 0xf >> >> @@ -71,4 +72,13 @@ extern CORE_ADDR aarch64_mte_set_ltag (CORE_ADDR address, CORE_ADDR tag); >> It is always possible to get the logical tag. */ >> extern CORE_ADDR aarch64_mte_get_ltag (CORE_ADDR address); >> >> +/* Given a TAGS vector containing 1 MTE tag per byte, pack the data as >> + 2 tags per byte and resize the vector. */ >> +void aarch64_mte_pack_tags (gdb::byte_vector &tags); >> + >> +/* Given a TAGS vector containing 2 MTE tags per byte, unpack the data as >> + 1 tag per byte and resize the vector. If SKIP_FIRST is TRUE, skip the >> + first unpacked element. Otherwise leave it in the unpacked vector. */ >> +void aarch64_mte_unpack_tags (gdb::byte_vector &tags, bool skip_first); > > All other declarations in the header have explicit "extern". > Done now. Thanks. >> + >> #endif /* ARCH_AARCH64_LINUX_H */ > > >> +/* Implementation of the "fetch_memtags" target_ops method. */ >> + >> +bool >> +core_target::fetch_memtags (CORE_ADDR address, size_t len, >> + gdb::byte_vector &tags, int type) >> +{ >> + struct gdbarch *gdbarch = target_gdbarch (); >> + >> + /* Make sure we have a way to decode the memory tag notes. */ >> + if (!gdbarch_decode_memtag_section_p (gdbarch)) >> + error (_("gdbarch_decode_memtag_section not implemented for this " >> + "architecture.")); >> + >> + memtag_section_info info; >> + info.memtag_section = nullptr; >> + >> + while (get_next_core_memtag_section (core_bfd, info.memtag_section, >> + address, info)) >> + { >> + size_t adjusted_length >> + = (address + len < info.end_address)? len : (info.end_address - address); > > Space before "?". > Fixed. >> + >> + /* Decode the memory tag note and return the tags. */ >> + gdb::byte_vector tags_read >> + = gdbarch_decode_memtag_section (gdbarch, info.memtag_section, type, >> + address, adjusted_length); >> + >> + /* Transfer over the tags that have been read. */ >> + tags.insert (tags.end (), tags_read.begin (), tags_read.end ()); >> + >> + /* ADDRESS + LEN may cross the boundaries of a particular memory tag >> + segment. Check if we need to fetch tags from a different section. */ >> + if (!tags_read.empty () && (address + len) < info.end_address) >> + return true; >> + >> + /* There are more tags to fetch. Update ADDRESS and LEN. */ >> + len -= (info.end_address - address); >> + address = info.end_address; >> + } >> + >> + return false; >> +} >> + > + > > >> + >> +bool >> +get_next_core_memtag_section (bfd *abfd, asection *section, >> + CORE_ADDR address, memtag_section_info &info) >> +{ >> + /* If the caller provided no SECTION to start from, search from the >> + beginning. */ >> + if (section == nullptr) >> + section = bfd_get_section_by_name (abfd, "memtag"); >> + >> + /* Go through all the memtag sections and figure out if ADDRESS >> + falls within one of the memory ranges that contain tags. */ >> + while (section != nullptr) >> + { >> + size_t memtag_range_size = section->rawsize; >> + size_t tags_size = bfd_section_size (section); >> + >> + /* Empty memory range and empty tag dump should not happen. */ >> + gdb_assert (memtag_range_size != 0); >> + gdb_assert (tags_size != 0); > > Seems like this could happen with corrupted input? GDB should not assert > on bad input. > I turned this into a warning and then we skip to the next section. >> + >> + CORE_ADDR start_address = bfd_section_vma (section); >> + CORE_ADDR end_address = start_address + memtag_range_size; >> + >> + /* Is the address within [start_address, end_address)? */ >> + if (address >= start_address >> + && address < end_address) >> + { >> + info.start_address = start_address; >> + info.end_address = end_address; >> + info.memtag_section = section; >> + return true; >> + } >> + section = bfd_get_next_section_by_name (abfd, section); >> + } >> + return false; >> +} > > >> --- /dev/null >> +++ b/gdb/testsuite/gdb.arch/aarch64-mte-gcore.c >> @@ -0,0 +1,93 @@ >> +/* This test program is part of GDB, the GNU debugger. >> + >> + Copyright 2021 Free Software Foundation, Inc. > > 2022 missing. > > Fixed now. >> diff --git a/gdb/testsuite/gdb.arch/aarch64-mte-gcore.exp b/gdb/testsuite/gdb.arch/aarch64-mte-gcore.exp >> new file mode 100644 >> index 00000000000..8a19c4b449e >> --- /dev/null >> +++ b/gdb/testsuite/gdb.arch/aarch64-mte-gcore.exp >> @@ -0,0 +1,107 @@ >> +# Copyright (C) 2018-2021 Free Software Foundation, Inc. > > 2021 -> 2022. > >> +# Run until a crash and confirm GDB displays memory tag violation >> +# information. >> +gdb_test "continue" \ >> + [multi_line \ >> + "Program received signal SIGSEGV, Segmentation fault" \ >> + "Memory tag violation while accessing address $hex" \ >> + "Allocation tag $hex" \ >> + "Logical tag $hex\." \ >> + "$hex in access_memory \\(.*\\) at .*" \ >> + ".*tagged_ptr\\\[0\\\] = 'a';"] \ >> + "display tag violation information for live process" >> + >> +# Generate the core file. >> +set core_filename [standard_output_file "$testfile.core"] >> +set core_generated [gdb_gcore_cmd "$core_filename" "generate core file"] > > I'd suggest also making sure gdb is able to read kernel-generated core properly. > You can use core_find to produce one. I spent a bit of time doing this. I wasn't aware of core_find. The testcase now exercises both gcore and native core files. v5 of this patch is on its way.