This is the mail archive of the gdb-prs@sources.redhat.com 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: gdb/1250 [regression] bad backtrace when function that calls 'abort' at end


The following reply was made to PR backtrace/1250; it has been noted by GNATS.

From: Michael Elizabeth Chastain <mec@shout.net>
To: gdb-gnats@sources.redhat.com
Cc:  
Subject: Re: gdb/1250 [regression] bad backtrace when function that calls 'abort' at end
Date: Sun, 10 Aug 2003 16:53:54 -0400

 Hmmm.  I just tried again with gcc 3.3, binutils 2.14, compiling with:
 
   gcc coremaker.c
 
 And things work for me too.  So I agree with you that "no -g" case is
 working fine.  Maybe I was on mild drugs when I tried it the last time,
 or maybe something improved in gdb in the past few days.
 
 I'm willing to close this PR now, how about you?
 
 As far as "cannot find start of function -> assume frame", I think that
 would be a mixed blessing.  There's lots of little grotty bits of
 assembly code that have no frame.  The killer part is that they often
 occur right at the innermost frame that calls an OS service, and in a
 multi-threaded program, most threads will be blocking on an OS service
 most of the time.
 
 Andrew had an idea to make this user-selectable.  Rather than set/show
 commands, how about options to the "backtrace" command.  The user can
 try "backtrace /frametype=1", "backtrace /frametype=2", and so on, until
 they see something useful that makes sense to them.
 
 Michael C


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