From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=default; t=1678221133; bh=PL4TZz/ltuhzMP+Ox+fkAMs2njY/qTXc4w6cMgv/D24=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=fB0WATvovO1Cuvu+9y3TzrchNTfgpgU9pZyY398rXy96ipprWG/MA/erbcaH/Bs+Z h2L/DOd+AAi857m6VQD8K7rQUrKIVYKjk1/P80D1PZv9ziVcu7gc7ifvYRKmOdBYWH 0VAgUVEktgfc97zq44qPY9nhQvBYkunQocUqmKbQ= 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> From: Simon Marchi 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-Spam-Status: No, score=-3031.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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 List-Id: 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