From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18677 invoked by alias); 4 Aug 2004 18:03:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 18670 invoked from network); 4 Aug 2004 18:03:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Aug 2004 18:03:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1BsQ5H-0005EC-GA; Wed, 04 Aug 2004 14:01:51 -0400 Date: Wed, 04 Aug 2004 18:03:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com, Roland McGrath Subject: Re: Identifying bottom-of-stack Message-ID: <20040804180151.GA20029@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com, Roland McGrath References: <41110832.7040104@gnu.org> <20040804171602.GA18438@nevyn.them.org> <41112000.5040102@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41112000.5040102@gnu.org> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-08/txt/msg00037.txt.bz2 On Wed, Aug 04, 2004 at 01:42:24PM -0400, Andrew Cagney wrote: > >On Wed, Aug 04, 2004 at 12:00:50PM -0400, Andrew Cagney wrote: > > > >>>Hello, > >>> > >>>In the multi-threaded case, GDB's having fun identifying the outer-most > >>>(oldest) frame and, unfortunatly, has this habit of backtracing past it > >>>:-/ > >>> > >>>Does anyone see a problem with: > >>> > >>>- GLIBC marking those outermost frames with CFI indicating that both the > >>>CFA and the RA are "unknown"? > >>> > >>>- GDB's CFI unwinder recognizing this and returning a NULL frame ID (gdb > >>>doesn't unwind _past_ such a frame). > >>> > >>>I think this would give us a portable way of terminating the stack. > >>> > >>>comments? > > > > > >This would make debugging in the outermost frame quite annoying, > >wouldn't it? We won't be able to find any frame relative variables. > > Why? Frame relative variables us DW_AT_frame_base. You're right. I still have the nagging feeling there's some other reason it matters, but since I can't think of specifics I'm probably just hallucinating again. -- Daniel Jacobowitz