Environment: gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure : (reconfigured) ./configure --enable-languages=c,c++,fortran,java,objc --no-create --no-recursion Thread model: posix gcc version 4.1.0 20051022 (experimental) ==== Program: #include <stdlib.h> int main( int argc, char** argv ) { abort( ); return 0; } ==== Compile command: gcc -O0 -ggdb -o test test.c ==== When run under 'gdb' then using the 'bt' commands results in #0 0xffffe410 in __kernel_vsyscall () #1 0x00afa118 in raise () from /lib/libc.so.6 #2 0x00afb888 in abort () from /lib/libc.so.6 #3 0x080483a5 in main (argc=Could not find the frame base for "main".) at test.c:4 ==== Works correctly with: gcc -v Using built-in specs. Target: i386-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --host=i386-redhat-linux Thread model: posix gcc version 4.0.1 20050727 (Red Hat 4.0.1-5) ==== backtrace then gives: 0 0xffffe410 in __kernel_vsyscall () #1 0x00afa118 in raise () from /lib/libc.so.6 #2 0x00afb888 in abort () from /lib/libc.so.6 #3 0x080483a5 in main (argc=Could not find the frame base for "main".) at test.c:4
What OS is this on, what kind of processor is this on also?
(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.
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 abort () from /lib/libc.so.6 #3 0x0804839d in main (argc=1, argv=0xbfa69a14) at office/test.c:4 Sorry. And, yes, I should have added the OS & hardware platform. Noted for future reference.
Leaving as P2.
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 return addresses to generate the backtraces. The return address from abort is one past the end of the call to abort, which is past the end of main. We are generating a location list for the frame base, since it differs between the prologue and the function body. This location list defines the value of the frame base at every point between function start and function end, and its value depends on the PC address you have. So gdb is taking a PC address from outside the main function, noticing that this address isn't covered by the frame base location list for main, and generating an error. Possible solutions: 1) Fix gdb to subtract one from a return address before processing the location list. This will ensure that we have an address inside the function, and thus an address for which we have a valid frame base. This is essentially what we do in the dwarf2 unwinder. 2) Pad the function with a nop, so that a return address always points to a valid instruction inside the function. This is what we do in the IA-64 port, to make IA-64 unwinding info work in this case. 3) Extend the location list info to run 1 byte past the end of the function. I don't know if this is safe. If the following function starts immediately after main, then we have two functions with debug info for the same byte of code. This may result in even more confusion than we already have. I think solution 1 should be investigated first, which means we need to get the gdb team to look at this. The problem with the return address can be seen by running "nm -S a.out | grep main" on the compiled testcase which gives you the starting address and size of main, and then comparing this against the PC address in the gdb backtrace. This shows that gdb is using an address 1 byte past the end of main for the backtrace.
I filed this as gdb PR 2024 in order to get a gdb opinion.
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 <stdio.h> #include <stdlib.h> int main( int argc, char** argv ) { printf( "hello world!\n" ); abort( ); int i = 0; int j = 1; printf( "i = %d, j = %d, total = %d\n", i, j, i + j ); return 0; } =========== I have not posted this comment on the gdb database as it may or may not be relevent to them but I think the point needs to be made.
(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 by the time we get to expand to RTL, the rest of the function has already deleted from the CFG as there is no way to get to the code (as it is unreachable code).
Not a gcc bug. This is a gdb bug, and I already have an approved patch for gdb that will be checked in shortly.