From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 5D6803857004 for ; Mon, 12 Sep 2022 13:53:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5D6803857004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "R3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 4MR7P16l9Rz3xQV; Mon, 12 Sep 2022 13:53:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MR7P15pPNz3tp4; Mon, 12 Sep 2022 13:53:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662990837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rx84KucOwfR15yLqkmq/fBfCqTMMWeKHAqTeRl1aWq4=; b=y15JIYcHGo34pLoTnRrzPSVnAWboS5FbBlMR3kAPYxVXgpe+cD8qsKDLCQTAZvjGZk0diq m/swCw1N7HRuwY4bf61fa+6u4iYtmB9q2rJeULp/dhENr2onb/K/USY8TKX8LBX8NJ6mJJ TM0P5TpLPJReP93xtw2K6yK2chdIRXrVEv7cFyKSdK9UbCfbDGkuKdWL1ila0FrEo9G3J0 xiCOilJkqYYosNDYcaQD+s9iNBBRI2M4yKsb5Y57Vv76qhMKMTVaKzPqo0moVr1tH6PE48 EkXPEnM26i1ZmQ7GeDQLFT/xTRZvQfl0ubTmNqLaXB0NvQEU404gqATTbM22eQ== Received: from [10.248.102.148] (global-5-141.n-2.net.cam.ac.uk [131.111.5.141]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4MR7P12LxxzV6J; Mon, 12 Sep 2022 13:53:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <42b0147c-22ac-1004-8b35-23008fffb481@FreeBSD.org> Date: Mon, 12 Sep 2022 14:53:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Content-Language: en-US To: Simon Marchi , Luis Machado , 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> From: John Baldwin Subject: Re: [PATCH] Update auxv cache when inferior pid is 0 (no inferior) In-Reply-To: <26831717-834d-91ee-fb08-55f787bd2421@simark.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1662990837; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rx84KucOwfR15yLqkmq/fBfCqTMMWeKHAqTeRl1aWq4=; b=rfx0czHuPH9bXnIhlGrJyGcdwXTuvucNbVuekCO3DNzIU85itjXBRJbSSA+vRf7pfTwX8c Yc8ZNA+PHThwUCFbKrr241gLlkuGb9UAwwMFOmWtqbXhxVt9S+Cw/+qX77ZiJX6EgWbkN8 W+PHgcpT+muHLlnJEBDKABITI1mTlK09Ulh3+XY34d0w9qiU50s8bQuGMTNKXNcV2m5lNx V+Yxr5DNBoXGsa0B+Q4yHKvarhcUfbmz8gb4uR5GHyCoZhV3W4f4W4oPIXJWnpf6jJ/D1K 7S1cFFVyq/vHyy7qfU+1i+mbKsqBYsXsr60ZIHGL9OjzKGtnw4xXqeuFEG9+gA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1662990837; a=rsa-sha256; cv=none; b=Wq0V4yrZnt7pMD1SqlSzquQw/SWcwDyY8FT48E5L0bDGF0k0eNiYjFH95PlZGh1eRvnqD3 f5SNuU3IW/3L02YeRl9Tc7TcsQFmvHZ5nLotHyIivKkkansZxEAg8Zi/vfnw492Sr48Y4H lihswv2MTLLmooCN/K0zHHca/IAguITzfwTYYEI7CIRbO7Zwwd0YZi6f2PoqPhI2FdhN+W IDmIc6Xhnv26q3k0z/p+CKZIvSH3qwEAtMuaTX2sU9uBpRJGO1DvvEEBhq0zpge99tzXSB /0qfmcisjjbbvBNwld4Z17v10ml4fMcy3eHzpRrFcNynDEy6ZkHbgritR5s+Og== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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 13:54:00 -0000 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. 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. -- John Baldwin