From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xGepBPth/mMK2wAAWB0awg (envelope-from ) for ; Tue, 28 Feb 2023 15:20:11 -0500 Received: by simark.ca (Postfix, from userid 112) id 036D51E222; Tue, 28 Feb 2023 15:20:11 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RDNS_DYNAMIC 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 85A321E128 for ; Tue, 28 Feb 2023 15:20:10 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C223A385840C for ; Tue, 28 Feb 2023 20:20:08 +0000 (GMT) Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by sourceware.org (Postfix) with ESMTPS id 46D153858D39 for ; Tue, 28 Feb 2023 20:19:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 46D153858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f54.google.com with SMTP id bt28so11059584wrb.8 for ; Tue, 28 Feb 2023 12:19:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1677615596; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sYqSE0iyOpJY9t4FuwqT9qwozzJNRsNAG5aN50420lM=; b=c4cyxs7auiAyJNX5xbgVKF3eL0GnYuRdD75BEfe4dJsgAdBL0Iq8bE4pCf1SzS4jzi q+uEfXJRNw48B8csKk4CVsZaH/A02ieMUQZFYJWS6eYH5m7L5bK2YJH9YBAzntaXkiml FvF+O2x4zfP9W0nlxwjT9D1TSTjSk9dENWewuIC36xWisewyepNwsQRRQe4npFAVwt/g QWJEzGbOWQnxsYfKJeVNfMTvm7XIGa5hDR3UxGzaF+jcrYCuv1+KlZXrbRxqZYrWTQ4y JVh9cQT4/C6NymnbHv4OkH46xAu4G2kBM82JdDviRmANG15XixDtSeu23dhp3KSS90IC pkuw== X-Gm-Message-State: AO0yUKX5u42uUJzHyHZwXiO0oWDvVDjHKq2q3QPx0kkddXV2AjG0Cuyt rpXcZLaRVSIAWnSi3mOeBKr+r4IUVSM= X-Google-Smtp-Source: AK7set+8aGkrt9++7YpCeuJSHV9xToveOj2OjPSSzw4AQ70d/sFmeKxmAIQp1Y6WwKxPDS1D5mzvoA== X-Received: by 2002:adf:ee0d:0:b0:2c7:da1:4694 with SMTP id y13-20020adfee0d000000b002c70da14694mr3099666wrn.62.1677615595955; Tue, 28 Feb 2023 12:19:55 -0800 (PST) Received: from ?IPv6:2001:8a0:f92b:9e00::1fe? ([2001:8a0:f92b:9e00::1fe]) by smtp.gmail.com with ESMTPSA id h10-20020a05600c350a00b003daffc2ecdesm18497802wmq.13.2023.02.28.12.19.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Feb 2023 12:19:55 -0800 (PST) Subject: Re: [PATCH] gdb: error out if architecture does not implement any "return_value" hook To: Andrew Burgess , Simon Marchi via Gdb-patches Cc: Simon Marchi References: <20230227212806.68474-1-simon.marchi@efficios.com> <87fsapj13v.fsf@redhat.com> From: Pedro Alves Message-ID: Date: Tue, 28 Feb 2023 20:20:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87fsapj13v.fsf@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US 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: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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()". > > 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.