Bug 32186 - -ggdb emits broken debug info
Summary: -ggdb emits broken debug info
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: debug (show other bugs)
Version: 4.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-debug
Depends on:
Blocks:
 
Reported: 2007-06-02 09:28 UTC by Ryan Johnson
Modified: 2021-09-17 01:11 UTC (History)
2 users (show)

See Also:
Host:
Target: i686-pc-cygwin
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Johnson 2007-06-02 09:28:36 UTC
Compiling with 'g++ -ggdb' confuses both gdb-6.5 and gdb-6.6 into thinking they've got corrupted stacks. My programs all seem to execute properly, both alone and inside gdb -- it's just hard to debug anything. Using 'g++ -g' instead seems to work fine.

Consider 'g++ -ggdb foo.cpp' with the following code snippet:

void foo() {
  int i;
  i=1;
}

int main() {
  foo();
  return 0;
}

Below is the gdb output as I step through the resulting executable. 

Current directory is c:/cygwin/home/johnsory/experiments/
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) start
Breakpoint 1 at 0x401071: file foo.cpp, line 6.
Starting program: /home/johnsory/experiments/a.exe 
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
main () at foo.cpp:6
(gdb) step
(gdb) bt
#0  main () at foo.cpp:7
(gdb) step
foo () at foo.cpp:1
(gdb) bt
#0  foo () at foo.cpp:1
#1  0x00401050 in mainCRTStartup ()
(gdb) step
(gdb) bt
#0  foo () at foo.cpp:3
#1  0x00401056 in foo () at foo.cpp:1
#2  0x00401056 in foo () at foo.cpp:1
#3  0x00401056 in foo () at foo.cpp:1
#4  0x00401056 in foo () at foo.cpp:1
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) step
(gdb) bt
#0  foo () at foo.cpp:4
#1  0x0040105d in foo () at foo.cpp:3
#2  0x0040105d in foo () at foo.cpp:3
#3  0x0040105d in foo () at foo.cpp:3
#4  0x0040105d in foo () at foo.cpp:3
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) step
main () at foo.cpp:8
(gdb) bt
#0  main () at foo.cpp:8
(gdb) step
(gdb) bt
#0  main () at foo.cpp:9
(gdb) step
0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll
(gdb) bt
#0  0x61006198 in dll_crt0_1 () from /usr/bin/cygwin1.dll
#1  0x61004416 in _cygtls::call2 () from /usr/bin/cygwin1.dll
#2  0x00000000 in ?? ()
(gdb) step
Single stepping until exit from function _Z10dll_crt0_1Pv, 
which has no line number information.

Program exited normally.
(gdb)
Comment 1 Ryan Johnson 2007-06-02 09:37:32 UTC
It also appears that 'next' is broken and acts like 'step' (enter all functions), while 'finish' acts like 'continue' (run to completion, barring a breakpoint).