From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2047.outbound.protection.outlook.com [40.107.21.47]) by sourceware.org (Postfix) with ESMTPS id 52CEE3857004 for ; Mon, 12 Sep 2022 14:00:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 52CEE3857004 ARC-Seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=QPzK/CntQCvsCiwieHeGWh8Ge6HlL8z6l8hFKwLYqElBIIyxG1zljIyn7Ht07phivxY15QZTJHujAMnlpUF4emSPQr31uWS5JCc67kJhTe9V8vHl8fao7rMCiAhADY6izo8OiwBK6KWCMgpNAjHO1Vxqm664c/nlDbFvSfnlaCZNzqyGek9Tzk05WbbOwo3zbDTZIxrr+XdVZUZSan/O9MF1XY/6YAEZvDVUL2accy2JSmbOpfEJdNJe5ttuXvBng27sxx/VjRfwffJuKc8BBAKmPZmPs8QKmSGbSFKs/J+U0rGfY51gUrsIhzXICxsVlE9jhMqFjMZ42qy6PdoD3g== 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=+jRG2MRYfSpJaOSFXYu9qQ3jmhzFeb7tuwZ5KHJICDM=; b=JYa1jV7kF4NqeMeTYkPBh0MZUtm3rGav9qtgPfhfQFZlS5x0a8rXUiq4jLS+XJRs8yeJTXrFIssi11cqPYdobt0E0ksoziTACQmcoP3jOpsC4sGT6EEfJYBssQJEWxP7m9zm6YUFiShqNsWmKwoVVyEnCv8todZqumQAuqCWpSWamx1C0+gRynlLL/gNwROzIsAh6eGUsFoER1s32JTsDMb2Wc5uRMQnYE4Sr4EyskxP4TsYrtVxUhzttg6lg1To8PU/sDiuY/6qUDA0OxucN7f4HQm/pMW3A+rIuFwBRK0O69KQ7xILpsUSfYl3K/4lgSZ7JWXhC7vjRl2xXkm9QQ== 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 DUZPR01CA0032.eurprd01.prod.exchangelabs.com (2603:10a6:10:468::11) by AS8PR08MB8109.eurprd08.prod.outlook.com (2603:10a6:20b:54b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.22; Mon, 12 Sep 2022 14:00:01 +0000 Received: from DBAEUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:468:cafe::e4) by DUZPR01CA0032.outlook.office365.com (2603:10a6:10:468::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.14 via Frontend Transport; Mon, 12 Sep 2022 14:00:01 +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 DBAEUR03FT032.mail.protection.outlook.com (100.127.142.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.13 via Frontend Transport; Mon, 12 Sep 2022 14:00:01 +0000 Received: ("Tessian outbound c883b5ba7b70:v123"); Mon, 12 Sep 2022 14:00:01 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 27e1e47d74917248 X-CR-MTA-TID: 64aa7808 Received: from 3e5e5aba7b36.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6E3A74BD-7C70-409B-8E77-16049CF1EBE1.1; Mon, 12 Sep 2022 13:59:54 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3e5e5aba7b36.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 12 Sep 2022 13:59:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XzUz4CJ+oFS4wpjbu8TKAZvZfvV+ZmeEaSd4tgHwhbi/8AexYxA/Kd+PRSD+usdKCR7FPjFWSl4iZ2y5refhXtGvm2KMlf1nDK0gnWxpvwoMZVjx1d8NRnCbxAf+84G9GyXDZqRNX25wjThbeZZbdHr9zGsIbGFIqipMrsHIbwsdRxKb3Ao1KnRBGr6kLGOfHEvYK4sjaOM3zBzkqBS7/upgOX2dFAn2FVqExvmZK9O/LfNTLHh2I+nr85u5VwaopmoZWTR2r/+/jgwEUnjiIKNVFevPQvbRtbQXyp8qZwHxaOecbiPMT4tEwGTBQA3G0Yc5DJ8TLRDKB1xap5tjzA== 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=+jRG2MRYfSpJaOSFXYu9qQ3jmhzFeb7tuwZ5KHJICDM=; b=HdOhefysncQ4RR+I/WQRPKYIRILvDditB24s/A3a3az/RVPEsQVrGbtbnpgmMC7Ll+OGVVTcNN5qcl0fLTOUMPY+usoKxKm92CFRtkAy/fDuTeOV2ROz3w1B1aBaM7sF3VJjB2zeOZvj0aeCUJEir2qTyZm93rnDXK/vQs2mO6SU5UY0bKIQn36ZOxOCcJo0/3uCtEnXS+s2AxSXkuhXVBNvQiDlS4oXPgWVaBDZbzPHyNwxPF6iE/ZE5KgCjQ/iPdROMMnvU9FAgU5nNssLyJlur+QTqZu4VwQUxXnT8Gn3cCBBCvSbWGkJ4noq+/iDQ/oyS/tmOYMszBXyG6CfJA== 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 AS2PR08MB9415.eurprd08.prod.outlook.com (2603:10a6:20b:595::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5612.12; Mon, 12 Sep 2022 13:59:53 +0000 Received: from VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094]) by VI1PR08MB3919.eurprd08.prod.outlook.com ([fe80::c5f9:a25b:a5f2:6094%5]) with mapi id 15.20.5612.022; Mon, 12 Sep 2022 13:59:52 +0000 Message-ID: <54ae3441-8b23-a746-91c1-da1e3535e42b@arm.com> Date: Mon, 12 Sep 2022 14:59:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Update auxv cache when inferior pid is 0 (no inferior) Content-Language: en-US To: John Baldwin , Simon Marchi , gdb-patches@sourceware.org References: <20220719144542.1478037-1-luis.machado@arm.com> <20220805154656.47903-1-luis.machado@arm.com> <26831717-834d-91ee-fb08-55f787bd2421@simark.ca> <42b0147c-22ac-1004-8b35-23008fffb481@FreeBSD.org> From: Luis Machado In-Reply-To: <42b0147c-22ac-1004-8b35-23008fffb481@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0655.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:316::9) To VI1PR08MB3919.eurprd08.prod.outlook.com (2603:10a6:803:c4::31) MIME-Version: 1.0 X-MS-TrafficTypeDiagnostic: VI1PR08MB3919:EE_|AS2PR08MB9415:EE_|DBAEUR03FT032:EE_|AS8PR08MB8109:EE_ X-MS-Office365-Filtering-Correlation-Id: dcc7d334-8bb6-4660-ce1b-08da94c715ef 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: Tsp00CuVYwqfVzeDmosU/H17cKvXtA+9O0nYi3JJ3ZNv2AYoVd9tHbpEtyZ1xxek4Ecq5RcnRFMPzyDpJr6KCctc4KVhQKtbeBu+VspwerXUTafjXULailvAfO2lR9f7TtFKtJRJ5I5EyPObI2UhbpeJPfwWzvKl7Td3gL+nBIohSbDv4AJmefcXfCkQZCQBnIqff222Ckg2Q+5HLmxIGFuyPSv3YOtniKZr8HYvEJp9sKDZXAowXzFJKKt0TYTNb9P4K6SF2EI+6udmLpB3Rr2fkpubCXFjzLgYNMwI5GHJJwk444f77HF6ExyWIrA7pdSTvNlMSLNvMhicg3AlwwAnyimzFlz9o2I6NWa9uWTcwI9Pjsf7usondjGr70fklP4wKREWg2FpPNeWbOjh+gt8icydZNTX6hSum7t206xc8GcvEcsaeHUAsT4I2hjBbuyT1z0iCSMUHOFiqHcIqko/CU+wbH8yGjQ+sOqU1RK311kx+w/c1aOXvdu8lSvf3nlVT5ldQFM0GCpKCzlFIiXoFPOy57Wu3Ayugenv6nrxluIYvPFn1GepdixFZ1IF7aY2P+7mUPqcIk4+icjd3NRlBnVWFKeWtQ0+P1kwQAgYTJGOD9ziCiTO+kA1gfOqScxRf1hBl0FD9Sk2sT9k+Oqhn8hN2wFKGyyRM9zKlh5OzyKmTTNDeqQ43/pfloLxAHru2BxDj+NhlF1a5EWFdZV3OFjod0b10BopaY/7s3+tfvQNUVx8MvgnHG66eUXpzo3LuOPQzYxKX7sfb3AHkT+hchw9+5EfrEW4jPi1/YM= 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)(396003)(366004)(39860400002)(136003)(376002)(346002)(31696002)(86362001)(2906002)(38100700002)(316002)(8936002)(110136005)(5660300002)(15650500001)(44832011)(8676002)(66946007)(66556008)(66476007)(2616005)(83380400001)(186003)(41300700001)(6506007)(6486002)(478600001)(26005)(6666004)(6512007)(53546011)(31686004)(36756003)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2PR08MB9415 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: DBAEUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id-Prvs: 33635d32-940c-4536-b93a-08da94c7106f X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 25QgpoHFNHtJlvSP1wC1h1Zh1sjiKBcuLugxKjztxUaFVtNoUHQKKivA75p7rCOtRNGluOzzx6h/Q2B3WuwuYcmfvANaH9r/WOV3E/VvqRX9uo6bLJV+QDdGoqBDTL3AC2/rUqJc2+pcPHO37/mFiGcEr4/9RD91gZxcG+/r4X+u+Rki7Ro5pzP+vaHYzqth0FGGt3dpHhq2qoeb0DPxJ2wKno+9GTyoOMwwO1Hz8hzVdKJeuR3kg5ONuhyChXqLWuPaulq6oUQ10eIHe3NMOFPJjpqHnmlJQaF7JvOmM8gEf2AOTM2sGwo+Cis6c93cWGrn8YjPr+6hB47CKKbW4j1gahZqL9iXLOHPGghGhIoY6rcFgyzTxW6AvjclX3wX1DCbz8Y1zEqYRSzY0FTutw4MMCSeuduKbFbkgxi7bqydSWcHLEo6awlrBzI/HzNRH20SWPEFQ/6SuJMyvnCHv1tBNaQdcu3elUYmHKTFgFmpSeK3Ehp0D9AL7JZnlQWWVCjNCj8Sz6lZ19iG6lMkbHSJhyYOXPseRaWi0Qxsenm9Mg+k99yySbLqhTeuKBsnzmRpkivpmn94vECabhqO7myHNrNQe0hnHmprFK00AAD1kGpHaI7ld+ndjuEFgvvRMjQfmgaCzV1k0LRUahIyBTS8g3W7yBROlzjNp/qQyUFhM+PyRqHyEmtAsgVe4tj66BzD13jSYd+Vfm0u/LJrbwomN4Pez5gOvZ2TQ4LMHHjcdF3bJQYCp4h5MBSc4OTApDlbKsuHWdf0HFxN9uLQ7e2tQZETw6Qmb5eWvstbsL1XTueYAm1fSUpUMDWMd9Q/ 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)(376002)(136003)(396003)(346002)(39860400002)(40470700004)(46966006)(36840700001)(110136005)(316002)(478600001)(8676002)(53546011)(6506007)(31686004)(5660300002)(44832011)(6666004)(15650500001)(2906002)(26005)(6512007)(47076005)(2616005)(70586007)(336012)(36756003)(70206006)(186003)(6486002)(83380400001)(40480700001)(82310400005)(81166007)(356005)(31696002)(36860700001)(8936002)(41300700001)(40460700003)(86362001)(82740400003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Sep 2022 14:00:01.3786 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dcc7d334-8bb6-4660-ce1b-08da94c715ef 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: DBAEUR03FT032.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR08MB8109 X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FORGED_SPF_HELO, 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, 12 Sep 2022 14:00:07 -0000 On 9/12/22 14:53, John Baldwin wrote: > On 9/12/22 2:30 PM, Simon Marchi via Gdb-patches wrote: >> >> >> On 2022-08-05 11:46, Luis Machado via Gdb-patches wrote: >>> While adding support for MTE corefiles and running the MTE corefile tests, >>> I noticed a strange situation where loading the symbol file + core file >>> through the command line has a different behavior compared to firing up >>> GDB, loading the symbol file with the "file" command and then loading the >>> core file with the "core" command. >>> >>> I tracked this down to gdb/auxv.c:get_auxv_inferior_data returning empty >>> auxv data for pid 0, which gets cached. This is triggered by attempting to >>> read auxv data for the exec target. >>> >>> In the early stages of reading the core file, we're still using inferior pid >>> 0, so when we attempt to read auxv to determine corefile features, we get the >>> cached empty data vector again. This breaks core_gdbarch setup. >>> >>> The fix, suggested by John Baldwin, prevents caching auxv data for pid 0. >> >> I read the thread where you discussed this with John, I'm not sure I >> completely grasp the problem yet, but this doesn't feel like the right >> fix.  It should be fine to cache the auxv data for an inferior with pid >> 0.  If the inferior's memory and the inferior's target stack don't >> change between two invocations of get_auxv_inferior_data, there's no >> reason for the auxv data to be different for both calls.  I think the >> problem is more that we don't invalidate the data at the right time. >> >> The first call is done when only the exec target is pushed.  The second >> call is done when the core target is pushed on top of that.  It's >> expected that the returned auxv data can be different for the two calls, >> so the cache should be invalidated somewhere between them. > > The problem is that the core target attaching is a multi-step process. > The auxv cache gets invalidated when the pid is changed from 0 to the > "real" value after reading the registers near the "end" of the core > target attach process.  However, in order to read the registers from the > core dump for some architectures (like Linux/AArch64), the > read_description_from_core gdbarch hook needs to be able to fetch auxv > data (specifically the AT_HWCAP bits).  This occurs while the pid is still > zero, so the old value from the exec target is still cached. > > This complexity is already present in the way that we fetch an "initial" > gdbarch from the core file and then ask that gdbarch for a more detailed > target description that is used to then instantiate a second gdbarch > (the "actual" gdbarch to use for the core file).  The place to possibly > flush the auxv cache again would perhaps be just before invoking the > core read_description method.  This would need a new observer hook though > that the auxv code could hook into. That's what I was thinking about. If we need to invalidate it, it would be during opening of the core file target. > > OTOH, pid 0 is rather special and short-lived, so caching auxv data for > it seems less important than caching it once a target is fully attached > to a core or running process, etc. > Also the fact that pid 0 (although a reasonable pid number) is really meant to be "no pid", as opposed to a real pid number 0.