This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: gdb/1250 [regression] bad backtrace when function that calls 'abort' at end
- From: Michael Elizabeth Chastain <mec at shout dot net>
- To: cagney at redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 10 Aug 2003 20:58:01 -0000
- Subject: Re: gdb/1250 [regression] bad backtrace when function that calls 'abort' at end
- Reply-to: Michael Elizabeth Chastain <mec at shout dot net>
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