Re: [wip] return value architecture method

[Corinna Vinschen <vinschen at redhat dot com>]

On Sun, Sep 28, 2003 at 12:53:54PM -0400, Andrew Cagney wrote:
> Hello,
> 
> This is a work-in-progress version of a "return_value" architecture 
> method.  This new method replaces:
> 
> USE_STRUCT_CONVENTION
> STORE_RETURN_VALUE
> EXTRACT_RETURN_VALUE
> RETURN_VALUE_ON_STACK
> 
> The idea, as illustrated in my recent patch to ppc64:
> http://sources.redhat.com/ml/gdb-patches/2003-09/msg00435.html
> is to put all the logic needed to determine how return values are 
> handled is written only once.
> 
> Notes:
> 
> I need to write doco.
> 
> It doesn't try to replace EXTRACT_STRUCT_VALUE_ADDRESS.  I'm not sure 
> what to do with that one.  I've a strong suspision that the 
> architectures that do implement it are actually broken - the callee 
> invalidates the register that contains the needed address so this 
> function can't work.  The change does at least clean up the logic 
> though, only calling EXTRACT_STRUCT_VALUE_ADDRESS after consulting 
> RETURN_VALUE.
> 
> This doesn't take a GCC_P parameter, but still takes the function's 
> return type.  There's a proposal to pass a function "struct value" 
> instead of the return type, but I think that can/should be made separatly.
>
> At present it is modifying value_being_returned.  As noted in another 
> post, some of this logic is going to be moved to print_return_value so 
> the final post will end up tweaking that as well.
> 
> This also finally makes it possible to fix:
> http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=659
> along with many many other cases where GDB was incorrectly claiming that 
> it wasn't able to find a return value.
> 
> anyway, thoughts?

Yes, various.

- 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?

- 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.

- 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".

- 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.

  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?


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.