From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9724 invoked by alias); 2 Mar 2006 18:36:22 -0000 Received: (qmail 9703 invoked by uid 22791); 2 Mar 2006 18:36:21 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.205) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Mar 2006 18:36:20 +0000 Received: by xproxy.gmail.com with SMTP id h29so313496wxd for ; Thu, 02 Mar 2006 10:36:18 -0800 (PST) Received: by 10.70.117.4 with SMTP id p4mr3660913wxc; Thu, 02 Mar 2006 10:36:18 -0800 (PST) Received: by 10.70.125.17 with HTTP; Thu, 2 Mar 2006 10:36:18 -0800 (PST) Message-ID: <8f2776cb0603021036s43843057yeeab086f86a8ef78@mail.gmail.com> Date: Thu, 02 Mar 2006 22:14:00 -0000 From: "Jim Blandy" To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: Suggestion: backtrace stop guard for threads callstacks In-Reply-To: <20060302175758.GA13025@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060302012943.GK1579@adacore.com> <20060302031921.GA24107@nevyn.them.org> <20060302175520.GB1330@adacore.com> <20060302175758.GA13025@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00055.txt.bz2 On 3/2/06, Daniel Jacobowitz wrote: > On Thu, Mar 02, 2006 at 09:55:20AM -0800, Joel Brobecker wrote: > > I understand. But I also thought that it would be nice to avoid printing > > the frames that are relative to thread startup code, and start the > > backtrace at the function the code used in the pthread_create call > > for instance. I think that the user won't be interested in them most > > of the time. > > Oh - actually stop the backtrace _before_ the library instead of _in_ > it? > > I'm not sure I agree; while the user may not be interested in the > library functions, you can call thread startup functions as normal > functions also; having backtraces stop without a clear indication > of why would be a little confusing too. I guess part of the problem here is that we're defining the problem in terms of recognizing frames after which we don't unwind, instead of saying, "These functions are part of the run-time and their frames shouldn't be listed normally." That way, you'd just mark _start and the thread startup trampoline, and you'd never get confused by recursive uses of main or calls to the thread initial functions from other places. In other words, we're somewhat off-by-one with our predicates. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9725 invoked by alias); 2 Mar 2006 18:36:23 -0000 Received: (qmail 9704 invoked by uid 22791); 2 Mar 2006 18:36:21 -0000 X-Spam-Check-By: sourceware.org Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.202) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Mar 2006 18:36:20 +0000 Received: by xproxy.gmail.com with SMTP id i31so314725wxd for ; Thu, 02 Mar 2006 10:36:18 -0800 (PST) Received: by 10.70.117.4 with SMTP id p4mr3660913wxc; Thu, 02 Mar 2006 10:36:18 -0800 (PST) Received: by 10.70.125.17 with HTTP; Thu, 2 Mar 2006 10:36:18 -0800 (PST) Message-ID: <8f2776cb0603021036s43843057yeeab086f86a8ef78@mail.gmail.com> Date: Thu, 02 Mar 2006 22:17:00 -0000 From: "Jim Blandy" To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com Subject: Re: Suggestion: backtrace stop guard for threads callstacks In-Reply-To: <20060302175758.GA13025@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060302012943.GK1579@adacore.com> <20060302031921.GA24107@nevyn.them.org> <20060302175520.GB1330@adacore.com> <20060302175758.GA13025@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00056.txt.bz2 Message-ID: <20060302221700.U-mVk3XtCMK5d_qiaqWbf99D4vt_AeQ1JgrT_9_dE-Y@z> On 3/2/06, Daniel Jacobowitz wrote: > On Thu, Mar 02, 2006 at 09:55:20AM -0800, Joel Brobecker wrote: > > I understand. But I also thought that it would be nice to avoid printing > > the frames that are relative to thread startup code, and start the > > backtrace at the function the code used in the pthread_create call > > for instance. I think that the user won't be interested in them most > > of the time. > > Oh - actually stop the backtrace _before_ the library instead of _in_ > it? > > I'm not sure I agree; while the user may not be interested in the > library functions, you can call thread startup functions as normal > functions also; having backtraces stop without a clear indication > of why would be a little confusing too. I guess part of the problem here is that we're defining the problem in terms of recognizing frames after which we don't unwind, instead of saying, "These functions are part of the run-time and their frames shouldn't be listed normally." That way, you'd just mark _start and the thread startup trampoline, and you'd never get confused by recursive uses of main or calls to the thread initial functions from other places. In other words, we're somewhat off-by-one with our predicates.