From: "Jim Blandy" <jimb@red-bean.com>
To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com
Subject: Re: Suggestion: backtrace stop guard for threads callstacks
Date: Thu, 02 Mar 2006 22:14:00 -0000 [thread overview]
Message-ID: <8f2776cb0603021036s43843057yeeab086f86a8ef78@mail.gmail.com> (raw)
In-Reply-To: <20060302175758.GA13025@nevyn.them.org>
On 3/2/06, Daniel Jacobowitz <drow@false.org> 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.
WARNING: multiple messages have this Message-ID
From: "Jim Blandy" <jimb@red-bean.com>
To: gdb-patches@sourceware.org, gdb-patches@sources.redhat.com
Subject: Re: Suggestion: backtrace stop guard for threads callstacks
Date: Thu, 02 Mar 2006 22:17:00 -0000 [thread overview]
Message-ID: <8f2776cb0603021036s43843057yeeab086f86a8ef78@mail.gmail.com> (raw)
Message-ID: <20060302221700.U-mVk3XtCMK5d_qiaqWbf99D4vt_AeQ1JgrT_9_dE-Y@z> (raw)
In-Reply-To: <20060302175758.GA13025@nevyn.them.org>
On 3/2/06, Daniel Jacobowitz <drow@false.org> 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.
next prev parent reply other threads:[~2006-03-02 18:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-02 1:29 Joel Brobecker
2006-03-02 3:19 ` Daniel Jacobowitz
2006-03-02 10:56 ` Andrew STUBBS
2006-03-02 17:38 ` Jim Blandy
2006-03-02 17:55 ` Joel Brobecker
2006-03-02 17:58 ` Daniel Jacobowitz
2006-03-02 18:36 ` Daniel Jacobowitz
2006-03-02 22:14 ` Jim Blandy [this message]
2006-03-02 22:17 ` Jim Blandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f2776cb0603021036s43843057yeeab086f86a8ef78@mail.gmail.com \
--to=jimb@red-bean.com \
--cc=gdb-patches@sources.redhat.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox