Re: [PATCH] gdb: error out if architecture does not implement any "return_value" hook

[Pedro Alves <pedro@palves.net>]

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.