This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Suggestion: backtrace stop guard for threads callstacks


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]