Re: [SO obvious...] make struct_return work for hand_function_call

[Andrew Cagney <ac131313@redhat.com>]

>   /* NOTE: cagney/2002-09-10: Only when the stack has been correctly
>      aligned (using frame_align()) do we can trust STRUCT_ADDR and
>      fetch the return value direct from the stack.  This lack of trust
>      comes about because legacy targets have a nasty habit of
>      silently, and local to PUSH_ARGUMENTS(), moving STRUCT_ADDR.  For
>      such targets, just hope that value_being_returned() can find the
>      adjusted value.  */
>   if (struct_return && gdbarch_frame_align_p (current_gdbarch))
>     {
>       struct value *retval = value_at (value_type, struct_addr, NULL);
>       do_cleanups (retbuf_cleanup);
>       return retval;
>     }

To be clear here, all architectures should implement frame_align.  With 
that method added, the above code is enabled and struct return works. 
Further, problems such as:

     if (gdbarch_frame_align_p (current_gdbarch))
       {
         /* NOTE: cagney/2002-09-18:

            On a RISC architecture, a void parameterless generic dummy
            frame (i.e., no parameters, no result) typically does not
            need to push anything the stack and hence can leave SP and
            FP.  Similarly, a framelss (possibly leaf) function does
            not push anything on the stack and, hence, that too can
            leave FP and SP unchanged.  As a consequence, a sequence of
            void parameterless generic dummy frame calls to frameless
            functions will create a sequence of effectively identical
            frames (SP, FP and TOS and PC the same).  This, not
            suprisingly, results in what appears to be a stack in an
            infinite loop --- when GDB tries to find a generic dummy
            frame on the internal dummy frame stack, it will always
            find the first one.

            To avoid this problem, the code below always grows the
            stack.  That way, two dummy frames can never be identical.
            It does burn a few bytes of stack but that is a small price
            to pay :-).  */

are also fixed.  BTW, frame_align and stack_align are different.  From 
the arch doco:

> @item frame_align (@var{address})
> @anchor{frame_align}
> @findex frame_align
> Define this to adjust @var{address} so that it meets the alignment
> requirements for the start of a new stack frame.  A stack frame's
> alignment requirements are typically stronger than a target processors
> stack alignment requirements (@pxref{STACK_ALIGN}).
> 
> This function is used to ensure that, when creating a dummy frame, both
> the initial stack pointer and (if needed) the address of the return
> value are correctly aligned.
> 
> Unlike @code{STACK_ALIGN}, this function always adjusts the address in
> the direction of stack growth.
> 
> By default, no frame based stack alignment is performed.

Andrew


Andrew