From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5dECLUDD/mOiGwEAWB0awg (envelope-from ) for ; Tue, 28 Feb 2023 22:15:12 -0500 Received: by simark.ca (Postfix, from userid 112) id A67FD1E223; Tue, 28 Feb 2023 22:15:12 -0500 (EST) 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=D7BvvMc/; 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=-5.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_MED,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 4E2711E110 for ; Tue, 28 Feb 2023 22:15:12 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5612D385840C for ; Wed, 1 Mar 2023 03:15:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5612D385840C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1677640511; bh=vD/kiMjofaYm2gWSFYAh5bPQDOzctlx781X6kxbysFY=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=D7BvvMc/LCRv/vleLi+KCRvG1u180c1XuY8QCLOn1+HtD1n6sZ2H8cPG8GaIri1Z3 OfFHhHrMrF6VkJTA8JBMEAUDtPSFgykT37TgqLjUUhVHp+JVNwPEeAqSc/B/M57Va6 cmhwSakf9FvJ+a9RY74Jsrn8aRQooCerC/plKVdg= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id A66DA3858D33 for ; Wed, 1 Mar 2023 03:14:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A66DA3858D33 Received: from [10.0.0.170] (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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id F22BD1E110; Tue, 28 Feb 2023 22:14:46 -0500 (EST) Message-ID: Date: Tue, 28 Feb 2023 22:14:46 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH] gdb: error out if architecture does not implement any "return_value" hook Content-Language: fr To: Pedro Alves , Andrew Burgess , Simon Marchi via Gdb-patches Cc: Simon Marchi References: <20230227212806.68474-1-simon.marchi@efficios.com> <87fsapj13v.fsf@redhat.com> In-Reply-To: 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 2/28/23 15:20, Pedro Alves wrote: > On 2023-02-28 2:50 p.m., Andrew Burgess via Gdb-patches wrote: > >> Or maybe we shouldn't be throwing an error in some of these cases, maybe >> in some cases we could warn and continue, just without the return value >> fetching? > > +1 > > It seems a bit too harsh for "finish" to error out, when it could just > not print the return value. get_return_value already returns NULL in > a couple scenarios where we can't get at the return value, for instance. > > For the "return" command, the patch is erroring out _after_ poping the frame. > There are legitimate cases where GDB won't be able to retrieve the return > value, like in the TYPE_NO_RETURN+query case handled in the function, which is > checked _before_ frame_pop. I'd think that if we are to error out when the arch > can't write the return value, we should do it before frame_pop too. Or we should > warn that we can't write the return value, and proceed anyhow. > > For ifuncs, calling the resolver and then erroring out is probably messing > up run control. It would probably be better to not try to resolve the ifunc > at all. > > For infcalls, I don't see a reason to error out if the user did "call func()" > instead of "print func()". I agree, I wrote this quickly to fix the problem, but didn't think all this through. >> >> As I said above, I don't actually like GDB trying to handling this case >> at all, I'd much rather we just force the port to stub these functions >> during bring up. > > There are legitimate cases when GDB isn't able to extract the return value. > Say, the function does not follow normal ABI. So we should already have > code in place that gracefully handles not being able to get at the return value. > If we code it right, then I guess in most cases an extra check for whether the > arch implements the return value hook wouldn't end up complicating the code, > it would just "fit right in". I'm not sure it's worth the bother, though. > I kind of tend to agree with you. Yeah, that all makes sense. If we en up with a way for gdbarch_return_value_as_value to return "I don't know", then it will be easy for people who write ports to start with a dummy implementation that always returns "I don't know". That could even be the default value for this gdbarch hook. In either case, GDB core indeed won't have to care about the case where the callback is missing. Simon Simon