From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> From: Simon Marchi In-Reply-To: <20220805154656.47903-1-luis.machado@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_PASS, 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:30:22 -0000 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