Re: [PATCH] gdb/amdgpu: provide dummy implementation of gdbarch_return_value_as_value

[Simon Marchi <simon.marchi@polymtl.ca>]

On 3/7/23 14:20, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> 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