Re: [wip] return value architecture method

[Andrew Cagney <ac131313 at redhat dot com>]

> - The enums RETURN_VALUE_REGISTER_CONVENTION and *_STRUCT_CONVENTION
>   are not good names for the meaning they have.  Instead of reflecting
>   the historical usage and having to explain what they mean in the
>   comment, they should more speak by themselves.  What about
>   RETURN_VALUE_IN_REGISTER and RETURN_VALUE_ON_STACK?

In the doco I wrote:

@value{GDBN} currently recognizes two function return-value conventions:
@code{RETURN_VALUE_REGISTER_CONVENTION} where the return value is found
in registers; and @code{RETURN_VALUE_STRUCT_CONVENTION} where the return
value is found in memory and the address of that memory location is
passed in as the function's first parameter.

Within GDB and GCC, the term "struct convention" has a very specific and 
long standing defintion: the address of that memory location is passed 
in as the function's first parameter.  That memory location does not 
need to be on the stack.

On the other hand, "on stack" convention would put the return-value at 
an ABI defined stack location.  To the best of my knowledge, no current 
GDB architecture uses this convention (but I suspect that in the past 
some did).  Please note that RETURN_VALUE_ON_STACK is really badly named.

> - The function address is missing.  If you have a target using multiple
>   ABIs which are intermixable, it might be of interest to get information
>   about the object file in which the function is implemented.  All the
>   nice functionality might be broken otherwise, if the same compiler is
>   using different ABIs in different files, because the object files are
>   compiled with different mach flags on the command line or if an automatism
>   should be used instead of letting the user choose the ABI.  You even
>   removed the gcc_p flag so there's nothing left to decide over a possibly
>   needed variation in behaviour.  However, the gcc_p flag isn't important,
>   the function address is.

As the doco points out:

@emph{Maintainer note: This method does not take a @var{gcc_p}
parameter, and such a parameter should not be added.  If an architecture
that requires per-compiler or per-function information be identified,
then the replacement of @var{rettype} with @code{struct value}
@var{function} should be persued.}

Since the architecture's I'm working on don't have a need for such a 
function, I avoided overengineering the change, adding not-yet-needed 
functionality.  The person that requires that change gets to resolve 
it's design issues.

> - I'm wondering why new target interface functions are created which do
>   not have the first parameter being a gdbarch pointer.  The gdbarch
>   pointer contains important information for subsequent function calls,
>   e.g. the tdep info.  IMHO, all new functions should always carry a
>   gdbarch pointer with them.  No, I don't think 
>
>     struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
>
>   is a good substitute.  I'd call that "retro-design".

This new architecture method's first parameter is "gdbarch" vis:

@item enum return_value_convention gdbarch_return_value (struct gdbarch 
*@var{gdbarch}, struct type *@var{valtype}, struct regcache 
*@var{regcache}, const void *@var{inval}, void *@var{outval})

> - If all these return value specific functions are replaced, I don't think
>   it's a good idea to do this without also addressing the
>   EXTRACT_STRUCT_VALUE_ADDRESS problem.  Typically gdb should have all
>   information it needs, it would just have to be given to the _return_value
>   function.

GDB typically does not have what it needs.  The doco notes:

(@var{regcache} contains a copy of the registers from the
just returned function)

The same clause apples equally to the existing methods.  The callee's 
frame has been well and truely lost.

>   Actually, from the function return type (and the ABI) you already
>   figure out that the return value is returned in register or on stack.
>   The missing information is the actual struct return address.  This is
>   stored in a register or on the stack (ABI dependant).  If the information
>   is on the stack, just use it.  If it's in a register, the register
>   might be clobbered by the callee, so just using the values in regcache
>   is somewhat borderline.  But we know, while the information might be
>   moved from that register to another register or onto the stack, it's
>   not lost since it's needed on returning from the function.
>
>   So can't we determine that information e.g. in the prologue scanning
>   code?  Typical implementation of the prologue heuristics used in various
>   targets make some handstands to determine what has happened to SP, PC
>   and, if used, FP.  Would it be hard to ask a target, which implements
>   _return_value, also to implement a more secure way to care for 
>   STRUCT_RETURN_REGNUM the same way?  And what about the debugging
>   information?  Doesn't Dwarf-2 give some information what has happened
>   to a register content?

Since the ABI considers the register "scratch", there's no requirement 
on the part of DWARF 2 CFI to provide unwind info.  Similarly, there's 
no requirement on the callee to follow any strict convention when saving 
that register.  Augmenting DWARF 2 so that the return-value address 
could be located would be a useful addition.

Further, for the case of an inferior-function call to a "struct 
convention" function, gdb saves the return-value address locally so it 
doesn't even need to re-locate that location.  In the past that wasn't 
the case, it had an unnecessary dependance EXTRACT_STRUCT_VALUE_ADDRESS.

Given this, I consider a correct implementation of "extract struct value 
address" to be very very a-typical, and plans to persue it to be 
orthogonal to this current change.

Andrew