From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2610:1c1:1:606c::19:2]) by sourceware.org (Postfix) with ESMTPS id A36FE3876893 for ; Mon, 25 Jul 2022 16:05:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A36FE3876893 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 4Ls4dj2q80z3Q5J; Mon, 25 Jul 2022 16:05:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4Ls4dj23mhz3RZd; Mon, 25 Jul 2022 16:05:45 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1658765145; 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=PfsnTfRooU7Lr82sw2Asu0emWkWzA7OK95kQjdpgmy4=; b=TVsqtmBp1y99raAsO9TjFZ9lIJed0PWB0iBdDEjSJbSOd0Gy1giiXEURFv4Cfd5fchc/FD Uq8UJUpcOPosqmRj6xS8QnBtMQeDbbDByWLxf3E8Vmtm/NtyUbQE3zf0TNW7cIeq5jXG1V jcz6l2bI/40vssHaFFQPeXahCtbg7bfVJ3kIChuRCew5nRCCtfrsbEOsn/CA+kLCdNzf7z USzVJ2eB3+evzaKz6BgWe86rcKlBo6yrjF4L62dHJPbXtWVi39kBaVCZgTWoda6N+NRvMt L7H8vy6NRAeNLiuFqLAo0ilgeo09tMq3Lrx3B3iKDVKX5peltGxoHVOSAJYYcQ== Received: from [10.0.1.4] (ralph.baldwin.cx [66.234.199.215]) (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 4Ls4dh6D9dz19sG; Mon, 25 Jul 2022 16:05:44 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <76097707-ed9e-1556-fac2-1992ab3cabae@FreeBSD.org> Date: Mon, 25 Jul 2022 09:05:43 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Content-Language: en-US To: Luis Machado , gdb-patches@sourceware.org References: <20220719144542.1478037-1-luis.machado@arm.com> From: John Baldwin Subject: Re: [PATCH] Update auxv cache when there is no auxv cached data In-Reply-To: <20220719144542.1478037-1-luis.machado@arm.com> 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=1658765145; 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=PfsnTfRooU7Lr82sw2Asu0emWkWzA7OK95kQjdpgmy4=; b=jR7tPrsYnDbbF05C/yL1kvwQE4Hr1r/hibE4G0stx5lorQYG5c/E2GnCm/5uK9EiEWK8IC DPNi/eGE9xZQVNJ0dO0vWHYZMSnY/UjygJ88Z6hVxjXKsqXxR7tWcDjtAJTz0OBj6vCGm/ bZT9P2BoQoRE9v+pkq2elpfOio1tCKccHslEdqF6PhjleMyAjSFmYZdc44Fr6vaJZjfQx1 iTOiO1db0HIK3gns3HqT0PJ8CAan9Owquhhjj3skC9QbhRSVAkcl9xrFfB1kLQwJhaxyV1 wKInXe/IJL2ooA/XVs2n+f0F+vE2HJr1Ar2pf6H7jDwdjychOivq1kNBsM8PlA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1658765145; a=rsa-sha256; cv=none; b=nFF69yhO/98JEHwPRHkAQtFFOx5N1GUcvs7ZD+uaeXNFRD+0l3Kec0oQ1SdM8ZyGAWJUOM GdLgRz0nr885cCAwPRxpVxul1s1X7VLIUHQny7ISM0CITu9Sb0c6bz151vujcpoJHOJU3w oXB/2wRJ1DyaIrnejVlzMiswTApZEuNbVklPYzJlTG00UekWhkfvRcFMAnlWJs50fDOHt0 EfEed4CZ5EBGXTHumIud60TDGiH0S9Y10eblx1gJd7mxugSc4VaB0/2RUKpB/BaUC6z0Q2 SyiGecbO4zl0RfkvINCckZsul3TMQsCMWel93Gb5NJPz042vw4Ub48JNmlJv2Q== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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, 25 Jul 2022 16:05:47 -0000 On 7/19/22 7:45 AM, 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 a valid > info struct, but with no auxv data. > > We've been doing the auxv caching for a while now, but sometime between > enabling auxv data caching and now, we turned the auxv data into an optional > value. The commit to use gdb::optional<> was this one in 2018: commit 9018be22e022e6db2ba07c4e407c7244022bc69a Author: Simon Marchi Date: Sat Apr 7 13:19:12 2018 -0400 Make target_read_alloc & al return vectors This patch started by changing target_read_alloc_1 to return a byte_vector, to avoid manual memory management (in target_read_alloc_1 and in the callers). To communicate failures to the callers, it actually returns a gdb::optional. Adjusting target_read_stralloc was a bit more tricky, since it wants to return a buffer of char, and not gdb_byte. Since you can't just cast a gdb::byte_vector into a gdb::def_vector, I made target_read_alloc_1 templated, so both versions (that return vectors of gdb_byte and char) are generated. Since target_read_stralloc now returns a gdb::char_vector instead of a gdb::unique_xmalloc_ptr, a few callers need to be adjusted. But looking at it's diff, it was always caching negative results even before this change. This is the relevant hunk of that commit: @@ -358,9 +356,8 @@ get_auxv_inferior_data (struct target_ops *ops) info = (struct auxv_info *) inferior_data (inf, auxv_inferior_data); if (info == NULL) { - info = XCNEW (struct auxv_info); - info->length = target_read_alloc (ops, TARGET_OBJECT_AUXV, - NULL, &info->data); + info = new auxv_info; + info->data = target_read_alloc (ops, TARGET_OBJECT_AUXV, NULL); set_inferior_data (inf, auxv_inferior_data, info); } So even before it seems that we would have cached a "negative" result. I believe your change will mean that we will keep asking over and over for the auxv data if a target doesn't support it and that it will only support positive caching. I wonder if a recent change means that in your test case something is trying to fetch the AUXV vector before the target can read it, e.g. trying to fetch AT_HWCAP* when determining the target description for a core file or the like? It seems like for the core target in corelow.c it should be fine to fetch AUXV data in the gdbarch_core_read_description hook though. Did you try setting a breakpoint for when this function was called to see when it is being cached? I wonder if the issue is that parsing the symbol file without a core is trying to fetch hwcap actually. Presumably a breakpoint would let you see that case? Maybe the fetch of hwcap needs to be guarded by something like "target_has_execution" or the like? -- John Baldwin