--- Comment #9 from wilson at gcc dot gnu dot org 2005-11-14 21:09 ---
Not a gcc bug. This is a gdb bug, and I already have an approved patch for gdb
that will be checked in shortly.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #8 from pinskia at gcc dot gnu dot org 2005-11-02 00:00 ---
(In reply to comment #7)
> I've just had a look at gdb PR 2024 and disagree with the comment "backtrace
> fails when function ends with call to abort". The following code also ehibits
> the problem noted here.
Well b
--- Comment #7 from kev dot gilbert at cdu dot edu dot au 2005-11-01 23:55
---
I've just had a look at gdb PR 2024 and disagree with the comment "backtrace
fails when function ends with call to abort". The following code also ehibits
the problem noted here.
==
#include
#inclu
--- Comment #6 from wilson at gcc dot gnu dot org 2005-11-01 23:22 ---
I filed this as gdb PR 2024 in order to get a gdb opinion.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from wilson at gcc dot gnu dot org 2005-11-01 02:44 ---
Even at -O0, we notice that main ends with a call to a function that does not
return, so the epilogue gets optimized away, and the last instruction in the
main function is the call to abort.
gdb is naively using retu
--- Comment #4 from mmitchel at gcc dot gnu dot org 2005-10-31 06:40
---
Leaving as P2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
--- Comment #3 from kev dot gilbert at cdu dot edu dot au 2005-10-23 22:13
---
Just for the record, I've pasted the incorrect gdb output for the second
backtrace. It is as follows:
#0 0x00240402 in __kernel_vsyscall ()
#1 0x00726118 in raise () from /lib/libc.so.6
#2 0x00727888 in a
--- Comment #2 from pinskia at gcc dot gnu dot org 2005-10-23 14:34 ---
(In reply to comment #1)
> What OS is this on, what kind of processor is this on also?
Never mind, I cannot read.
Anyways confirmed, a regression from 4.0.0.
--
pinskia at gcc dot gnu dot org changed:
