From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4473 invoked by alias); 23 Jul 2004 00:46:38 -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 4465 invoked from network); 23 Jul 2004 00:46:37 -0000 Received: from unknown (HELO barry.mail.mindspring.net) (207.69.200.25) by sourceware.org with SMTP; 23 Jul 2004 00:46:37 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BnoCm-0001x9-00; Thu, 22 Jul 2004 20:46:32 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 8B6A04B104; Thu, 22 Jul 2004 20:46:54 -0400 (EDT) To: brobecker@gnat.com, kettenis@chello.nl Subject: Re: [6.2] PROBLEMS file Cc: cagney@gnu.org, eliz@gnu.org, gdb@sources.redhat.com, hjl@lucon.org Message-Id: <20040723004654.8B6A04B104@berman.michael-chastain.com> Date: Fri, 23 Jul 2004 05:44:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-07/txt/msg00291.txt.bz2 joel> FWIW: As a user, I don't mind when the unwinder goes too far and joel> displays too many frames. The info we're looking for is there, and joel> that's what really counts for me. Not pretty, but good enough. joel> So I wouldn't mind closing that particular PR, especially since joel> there doesn't seem to be any accurate way of detecting the top joel> of the call stack. There are really two separate problems here. gdb/1505 is all about top-of-stack detection. How about we document the limitation and live with it. The existing text is: Most programs have a standard user entry point---a place where system libraries and startup code transition into user code. For C this is @code{main}. When @value{GDBN} finds the entry function in a backtrace it will terminate the backtrace, to avoid tracing into highly system-specific (and generally uninteresting) code. How about adding something like this: @value{GDBN} is not perfect at detecting the top of the call stack. For instance, if your program creates multiple threads, then the stack of an individual thread may not start with @code{main} at all. So you may see strange frames at the top of the stack; it is safe to ignore these. If we document it, I am okay with closing the PR. (And while I was reading the doco I noticed "set backtrace limit" is already implemented, which is exactly what I want for callfuncs.exp!) The other problem is strange frames in the middle that cause the trace to go bad before it gets to any interesting user code. That's a different, and much worse, problem, but it's not PR gdb/1505. See PR gdb/1255 and PR gdb/1253. Those two particular PR's have been fixed. Michael C