From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22966 invoked by alias); 4 Aug 2004 18:12:02 -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 22955 invoked from network); 4 Aug 2004 18:12:00 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 4 Aug 2004 18:12:00 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i74IC0e1004767 for ; Wed, 4 Aug 2004 14:12:00 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i74HgVa29301; Wed, 4 Aug 2004 13:42:31 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1F4CE2B9D; Wed, 4 Aug 2004 13:42:25 -0400 (EDT) Message-ID: <41112000.5040102@gnu.org> Date: Wed, 04 Aug 2004 18:12:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040801 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com, Roland McGrath Subject: Re: Identifying bottom-of-stack References: <41110832.7040104@gnu.org> <20040804171602.GA18438@nevyn.them.org> In-Reply-To: <20040804171602.GA18438@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-08/txt/msg00038.txt.bz2 > 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. > I realize users rarely need to do this, but if we're going to design a > solution it should take this into account.