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 21BA138582A7 for ; Tue, 2 Aug 2022 16:05:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21BA138582A7 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 4Ly0FK6WP5z4NcF; Tue, 2 Aug 2022 16:05:09 +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 4Ly0FK5fGcz3mNv; Tue, 2 Aug 2022 16:05:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659456309; 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=F+J2KZj+ywMziigqhzNUKCJAZolBna2IOA+GEESoevk=; b=bZucFAl+91ogB83QAe6Tapgm51PAwxReJYBMIrRZ6UV5oXDbaCAXZaPcX1hJN+0FmUMpaz SWCnJxT22J6QGtuukcPRCHyrAO2aX5u/RlwaI23JHUZJnNvXiae/z/QQzI/o0C/zKX8+OK cIr11UwgVCMafp/ZZJy7DcscaHLgBWPFUaQrD9atqZoku05+DfKC8Z6HYANxC78PPblulZ inLYln+MwMbM9/RDhpsfbFvnAUl6KXvkE7kPbPHGuEWItvvMavYw4c/sh6oIzuCtjEz4pq YnlJp9TW9DEi5SL6kRxPduBQTzZMaowM48twT3p7hF96T48zGpLugNxLjAL8eQ== 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 4Ly0FK2W74zTZC; Tue, 2 Aug 2022 16:05:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <31524689-4159-81ee-14c0-7d7db20bd839@FreeBSD.org> Date: Tue, 2 Aug 2022 09:05:08 -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> <76097707-ed9e-1556-fac2-1992ab3cabae@FreeBSD.org> From: John Baldwin Subject: Re: [PATCH] Update auxv cache when there is no auxv cached data In-Reply-To: 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=1659456309; 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=F+J2KZj+ywMziigqhzNUKCJAZolBna2IOA+GEESoevk=; b=Jrm7zNX73UqeDfKEGDddUaPRpP9POMvD67Frjj5vVcqjHd6KF2z5MTgnpuT4sQIRLDWfLP NCk5MzH7krf3TZ5d/A03sghDVLKXms/COQn0jhWEbb2Cv8TWW2HLR7gzkM/dR33D/rPB0O UxFINoKsgeYtL75uSFx7XkQ3kRip9ua5IjbrKCHG1QXcxc8iiNGkc65uMSjZBC2yK2vYLg bMZuJpkcMQ6ZQtATYBGfsqa1ByhIkHaSr8UUwr1cnHnqU9gtw70n2Aghn5Qk4XXlcYJxDJ qB1bc+kEnrFzJM0AnL276MbnQXBgav7imoxt5pVZQAuanIJVvsCY+PcV5svNkA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659456309; a=rsa-sha256; cv=none; b=rDF3eRrJHTn1Z7AeZdIYF8Z5sr8qMffRJLekiP/rO5iRBKsZ/VT7bu2Dpf+I9w9UEOccQS SUYTmPcXgMsRLobiAS7xVYIC2WymzsU7aU43Kqs3FmIBgBaUgdjeS+azyWpgR/PVbM0yWb xxzfNjsqUzP+KxNsYPihi9MyObMs3TROIMNkS5qgLw9wt1+vabVTSJXvOVxMqXZSydF/+E fl1c7B1IWaBnbQ+GaCGc1VAl6uP6WjyKco9/aHe8vUiTH3iFvg2jgo0buidnx2RUv2V3lW W5MNpxK40PCB30nN9BImzP6z7cD9FqmAkxqviCGxkaTLuR4awgrNSSmog25x+g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, 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: Tue, 02 Aug 2022 16:05:11 -0000 On 8/2/22 8:05 AM, Luis Machado wrote: > Here's the sequence of events for each invocation mode: > > 1 - Loading core file only (OK) > > Invocations: > gdb -c exec.core > gdb -ex "core exec.core > > In this mode, GDB will load the core file and eventually invoke the constructor in core_target_open: > > core_target *target = new core_target (); > > This constructor will attempt to retrieve the target description, and it won't find a XML note in the core file because this > was generated by the Linux Kernel. So eventually it will invoke aarch64_linux_core_read_description, which *will* try to > retrieve the hwcap bits. > > In this case, it works because we don't have any auxv entries cached for inferior with pid 0, so we proceed to fetch the corefile's > auxv section data. > > Eventually we will figure out the real pid for the core file inferior and we will fetch the target description again and > things just work. > > > 2 - Loading exec file and core file (OK) > > Invocations: > gdb exec -c exec.core > gdb -ex "file exec" -c exec.core > gdb -ex "core exec.core" -ex "file exec" > > Loading the exec file through the command line (not using the file command) doesn't force the svr4 relocation > functions to be called, and thus doesn't attempt to fetch the auxv (none available) and cache it (empty). > > When using the file command to load the exec file, we eventually attempt to fetch the auxv (none available) and > cache it (empty). > > With that in mind, these invocations will always cause the corefile handling routines to be the first ones to attempt > to fetch the auxv data, so this will in fact cache valid data and things just work normally. > > > 3 - Loading exec file and core file (Broken) > > Invocation: > gdb -ex "file exec" -ex "core exec.core" > > Having in mind the explanation from (2), this invocation will first attempt to fetch auxv data for the exec target and will > cache empty data, because the exec target doesn't have auxv entries. This will be cached for inferior pid 0. > > Afterwards, we process the corefile and during the construction of the core_target, the aarch64 code will attempt to > fetch the auxv data, but at this point we still have inferior pid 0, since we didn't read the registers yet. > > Given we cached the empty auxv data from the exec target earlier, we will get that when we attempt to fetch the auxv data > for the core file, which is incorrect. > > This will throw off the target feature detection for aarch64, and so we won't register the required hooks (in particular report_signal_info). > > Loading the corefile proceeds as usual and we will eventually find the pid for the corefile inferior, which causes the cached auxv entry to be > invalidated and we fetch the auxv again, but with a valid inferior pid. > > What actually goes wrong now is the fact that core_gdbarch was not calculated correctly due to the auxv situation. But the gdbarch (not core_gdbarch) is > correct though. > > There are some odd things that I noticed: > > - The use of pid 0 for both the exec and the core file at the same time. > - The use of core_gdbarch as opposed to using the regular gdbarch. It feels like we have a couple gdbarch's when we should have only one. > - The handling of non-existent / empty auxv is not great. Should we cache an empty auxv? Should we cache a non-existent auxv value? > > An easy fix would be to not use hwcap bits for detecting corefile features, instead relying on dumped register sections. But we should be able to use > information that is available through the auxv. FWIW, for FreeBSD so far I have relied on the register sets present to determine the target description (both for ARM and x86 architectures), in part because the presence of register set notes is what ensures the core file can supply the relevant registers. This is also true for Linux/x86 though part of the reason for this is that on x86 we need the value of the xcr0 register to determine what register sets are contained in the XSAVE note and that isn't described by HWCAP bits but instead a copy of xcr0 is saved in the XSAVE note at a fixed offset. (Actually, 32-bit arm on FreeBSD does use AT_HWCAP as well to determine the type of VFP registers.) That said, I wonder if what might make sense is to not cache auxv data for pid 0. pid 0 is the special "not yet fully ready" inferior. (In fact, the check I had envisioned for guarding svr4_relocate_file could possibly be expressed as the pid != 0.) This would cache auxv data once an inferior was fully "live" but would work permit case 3) to work. Something like: diff --git a/gdb/auxv.c b/gdb/auxv.c index 8e175138f5d..53fd66dd3af 100644 --- a/gdb/auxv.c +++ b/gdb/auxv.c @@ -361,7 +361,7 @@ get_auxv_inferior_data (struct target_ops *ops) struct inferior *inf = current_inferior (); info = auxv_inferior_data.get (inf); - if (info == NULL) + if (info == NULL || inf->pid == 0) { info = auxv_inferior_data.emplace (inf); info->data = target_read_alloc (ops, TARGET_OBJECT_AUXV, NULL); I know previously I said I didn't like overwriting the cached info as your original patch did, but looking at the existing uses of get_auxv_inferior_data trying to teach them cleanly to discard the returned data for pid 0 and not otherwise seemed ugly. There is still a downside that this will return the "last" cached auxv data for pid 0 once the pid changes, but the pid changing should trigger cache invalidation via one of the observers so I think it's ok. -- John Baldwin