From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oGYpFqCfB2TJvwcAWB0awg (envelope-from ) for ; Tue, 07 Mar 2023 15:33:36 -0500 Received: by simark.ca (Postfix, from userid 112) id 576821E223; Tue, 7 Mar 2023 15:33:36 -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=q/ufPM0Y; 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=-9.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_DNSWL_HI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.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 6CD6A1E222 for ; Tue, 7 Mar 2023 15:33:35 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E31B4385417F for ; Tue, 7 Mar 2023 20:33:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E31B4385417F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1678221214; bh=PL4TZz/ltuhzMP+Ox+fkAMs2njY/qTXc4w6cMgv/D24=; 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=q/ufPM0Yoh8iw/DQx9v2qvgbxKYKhOnWN2QypUUfj7i6TTeKzkDIQnx7c3lLQ7Too JNVPIydh1VmKVvFdKmN8mZxBVehUuApxUI+y1n6mdqO5JzlsNqmhGsf69vEip4VEwy md3GK9HWU30BL8BoMyB6tuV01V8lgiwxJLlg//Ko= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id BCC683858C30 for ; Tue, 7 Mar 2023 20:33:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BCC683858C30 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 327KW7Ij017912 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Mar 2023 15:32:12 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 327KW7Ij017912 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 92D8A1E128; Tue, 7 Mar 2023 15:32:07 -0500 (EST) Message-ID: Date: Tue, 7 Mar 2023 15:32:07 -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/amdgpu: provide dummy implementation of gdbarch_return_value_as_value Content-Language: en-US To: Tom Tromey , Simon Marchi via Gdb-patches Cc: Lancelot SIX References: <20230306214650.1744872-1-simon.marchi@polymtl.ca> <20230307104556.6irap5z2epv7ppxq@ubuntu.lan> <5f905345-15a1-d7e0-f8b5-221997fcd1ac@polymtl.ca> <878rg8s70t.fsf@tromey.com> In-Reply-To: <878rg8s70t.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 7 Mar 2023 20:32:07 +0000 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 3/7/23 14:20, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi via Gdb-patches writes: > > Simon> I think that Pedro hinted that we would need this anyway at some point, > Simon> for functions that don't follow a defined ABI. So, I think it would > Simon> make sense, but we need to update the core of GDB to handle that > Simon> response. > > Can we even detect this situation? > > E.g., PR 30090 turned out to have a function with a nonstandard ABI, and > in the end I just xfail'd the test. I chatted about this with Pedro offline, and that was my question. Apart from the "I'm half way through implementing a port" situation, is there really a case where a function won't have a standard ABI, it won't be marked as such in the DWARF (with is already handled with the is_nocall_function check) and the arch code will be able to know? Our intuition was, probably not. So we concluded that it didn't make sense to add a RETURN_VALUE_UNKNOWN enumerator for the amdgpu case, since it would just be temporary until we submit the real code. In the mean time, it's not really possible to reach that place anyway. And even if we could, it's expected that the AMD GPU port is not really usable in master anyway as of today. > Simon> And I'm not too familiar with this area, so I don't know how > Simon> much work this represents. But if we know we're going to need this > Simon> anyway, I might as well give it a shot. > > There aren't many callers of the gdbarch hooks so I guess you could just > track them all down and see what needs to be done at each one. There's > definitely already code to handle the lack of a return value, so it > seems like it may not be too hard. Yes, that's what we would have done, had we decided to go forward with that solution. I will go aheady and push this patch, to unbreak the port. Simon