From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8832 invoked by alias); 31 Jul 2003 22:27:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 8825 invoked from network); 31 Jul 2003 22:27:55 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 31 Jul 2003 22:27:55 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1D4A22B7F; Thu, 31 Jul 2003 18:27:54 -0400 (EDT) Message-ID: <3F2997EA.3080502@redhat.com> Date: Thu, 31 Jul 2003 22:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder Cc: gdb-patches@sources.redhat.com Subject: Re: [SO obvious...] make struct_return work for hand_function_call References: <3F28321A.7040201@redhat.com> <3F287E4D.9040106@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00568.txt.bz2 > /* 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