Re: [RFA] Locate sparc64 arguments correctly

["David S. Miller" <davem@redhat.com>]

   From: Michael Snyder <msnyder@redhat.com>
   Date: Tue, 23 Apr 2002 12:41:20 -0700

   "David S. Miller" wrote:
   > Two problems:
   > 
   > 1) Debugging information encodes LOC_ARG/LOC_REF_ARG offsets
   >    with the Sparc64 stack bias included, we keep track of the
   >    frame pointer with the stack bias removed on sparc64.
   > 
   >    sparc64_frame_args_address takes care of that.
   
   This is a good idea, but FRAME_ARGS_ADDRESS is multi-arched.
   Can you use that implementation?
   
I do this in my patches, as per:
   
   > --- sparc-tdep.c.~1~    Sat Apr 20 01:46:27 2002
   > +++ sparc-tdep.c        Sat Apr 20 01:52:38 2002
   > @@ -2798,6 +2798,16 @@ sparc64_register_byte (int regno)
   >      return 64 * 8 + (regno - 80) * 8;
   >  }
   > 
   > +/* Debugging information stores LOC_ARG/LOC_REF_ARG offsets with the
   > +   sparc64 stack bias present, this undoes that so that users of
   > +   FRAME_ARGS_ADDRESS use the right location.  */
   > +
   > +static CORE_ADDR
   > +sparc64_frame_args_address (struct frame_info *fi)
   > +{
   > +  return fi->frame - 2047;
   > +}
   > +

I have to do the tm-sp64.h non-multi-arch'd version too in order
to prevent potential breakage until Sparc is %100 multi-arch'd.

   > 2) REG_STRUCT_HAS_ADDR was wrong, structs larger than 16 bytes
   >    are passed by reference.
   
   Have you verified that this is the case on Solaris?
   
This is what the GCC backend uses, and is what the Sysv4 Sparc 64-bit
ABI specifies.

   > No regression test changes, likely because these things aren't
   > hit by the testsuite.
   
   How about extending testsuite/gdb.base/structs.[c exp]
   so that they cover this case?
   
The reason the regressions didn't change turned out to not be because
the testsuite didn't test it, it was because the current sparc64 arg
passing code would fix up these case by itself.

Franks a lot,
David S. Miller
davem@redhat.com