This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [SO obvious...] make struct_return work for hand_function_call
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Michael Snyder <msnyder at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 31 Jul 2003 18:27:54 -0400
- Subject: Re: [SO obvious...] make struct_return work for hand_function_call
- References: <3F28321A.7040201@redhat.com> <3F287E4D.9040106@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