This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


  /* 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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]