From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kmJvNIE0H2O1bDgAWB0awg (envelope-from ) for ; Mon, 12 Sep 2022 09:30:41 -0400 Received: by simark.ca (Postfix, from userid 112) id C771A1E110; Mon, 12 Sep 2022 09:30:41 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=oBmWAgEb; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 670081E0D3 for ; Mon, 12 Sep 2022 09:30:41 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8D10F3856248 for ; Mon, 12 Sep 2022 13:30:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8D10F3856248 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1662989440; bh=zdsi7W+Ejhdc+zlQn6Iq7Ec/CtRcDgdtTyB+jbavAxA=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=oBmWAgEb2DJXrSZFv5aKJOG7p1mGGGSnLaL0DS1PPvtIGklB8LlYKjE5ebLX+xDtq 6l/sUY3Px+xfDmF86CeHKiTzNsKEKTUJtGUHO7UfcbEipfY07vOaXjSvvWV4ms6pSJ o6i4wawzt9uuPFCUNdD98pii5KhhDF/MDf2pcUe0= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id D83823857011 for ; Mon, 12 Sep 2022 13:30:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D83823857011 Received: from [10.0.0.11] (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 861931E0D3; Mon, 12 Sep 2022 09:30:19 -0400 (EDT) Message-ID: <26831717-834d-91ee-fb08-55f787bd2421@simark.ca> Date: Mon, 12 Sep 2022 09:30:19 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH] Update auxv cache when inferior pid is 0 (no inferior) Content-Language: en-US To: Luis Machado , gdb-patches@sourceware.org References: <20220719144542.1478037-1-luis.machado@arm.com> <20220805154656.47903-1-luis.machado@arm.com> In-Reply-To: <20220805154656.47903-1-luis.machado@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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. Simon