From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8928 invoked by alias); 18 Jun 2002 23:52:08 -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 8860 invoked from network); 18 Jun 2002 23:52:01 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 18 Jun 2002 23:52:01 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id E81C03D92; Tue, 18 Jun 2002 19:52:00 -0400 (EDT) Message-ID: <3D0FC7A0.10601@cygnus.com> Date: Tue, 18 Jun 2002 16:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Tru64 stack unwinding fix References: <20020614120726.G17001@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00356.txt.bz2 > I'm sorry the test case involves Ada, but that is the only way > I found to reproduce it at the time when I looked at this problem. I suspect a non-ada aware GDB and a breakpoint on *__hstTransferRegistersPC would do the trick :-) > Here is the ChangeLog: > 2002-06-14 Joel Brobecker > * alpha-tdep.c (heuristic_proc_desc): Compute the size of the > current frame using only the first stack size adjustment. All > subsequent size adjustments are not considered to be part of > the "static" part of the current frame. > Compute the address of the saved registers relative to the > Frame Pointer ($fp) instead of the Stack Pointer if $fp is > in use in this frame. > > Ok to commit? Yes (you're in a better position then most to test it). The change to handle FP and alloca() is very important and something often missed. > + /* At this point, we know which of the Stack Pointer of the Frame Pointer .. or the .. enjoy, Andrew PS: Some things unrelated to your patch I noticed: > ! vfp = read_next_frame_reg (next_frame, ALPHA_GCC_FP_REGNUM); I think someone should re-implement read_next_frame_reg() using: /* Unwind the stack frame so that the value of REGNUM, in the previous frame is returned. If VALUEP is NULL, don't fetch/compute the value. Instead just return the location of the value. */ extern void frame_register_unwind (struct frame_info *frame, int regnum, int *optimizedp, enum lval_type *lvalp, CORE_ADDR *addrp, int *realnump, void *valuep); as this will work with CFI and generic dummy frames.