From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3690 invoked by alias); 19 Jun 2002 01:20:24 -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 3658 invoked from network); 19 Jun 2002 01:20:20 -0000 Received: from unknown (HELO takamaka.int.act-europe.fr) (142.179.108.207) by sources.redhat.com with SMTP; 19 Jun 2002 01:20:20 -0000 Received: by takamaka.int.act-europe.fr (Postfix, from userid 507) id 518A289FBA; Tue, 18 Jun 2002 18:20:19 -0700 (PDT) Date: Tue, 18 Jun 2002 18:20:00 -0000 From: Joel Brobecker To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Tru64 stack unwinding fix Message-ID: <20020618182019.O2828@gnat.com> References: <20020614120726.G17001@gnat.com> <3D0FC7A0.10601@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3D0FC7A0.10601@cygnus.com>; from ac131313@cygnus.com on Tue, Jun 18, 2002 at 07:52:00PM -0400 X-SW-Source: 2002-06/txt/msg00358.txt.bz2 > > 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. Thanks. This is now in (I also corrected the little typo you found in one of the comments). > I suspect a non-ada aware GDB and a breakpoint on > *__hstTransferRegistersPC would do the trick :-) Yes it did, silly me :-). Just for the record, here is the output before my patch: << (gdb) b __hstTransferRegistersPC Breakpoint 2 at 0x3ff8057d43c (gdb) c Continuing. Breakpoint 2, 0x000003ff8057d43c in __hstTransferRegistersPC () from /usr/shlib/libpthread.so (gdb) bt #0 0x000003ff8057d43c in __hstTransferRegistersPC () from /usr/shlib/libpthread.so #1 0x000003ff8056e8e4 in __osTransferContext () from /usr/shlib/libpthread.so warning: Hit beginning of text section without finding warning: enclosing function for address 0x13 >> > 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. Ack, I'll try to do this when I have a spare moment... Thanks for the quick review. -- Joel