I created a simple Hello world executable using Cygwin on my Windows 7 PC, building it with: gcc hello.c -g
I can use gdb from the command line on the executable with no problem.
Then in Eclipse Kepler I created a debug configuration with these settings: - The C/C++ Application has the full path to the executable - It is not connected to a project; the Project box is blank. The workspace doesn't have any projects in it. - "Disable auto build" is selected - "Stop on startup at: main" is selected - The GDB debugger is set to C:\cygwin64\bin\gdb.exe - I added the full path to the directory containing hello.c and the executable to the "Source Lookup Path"
My original problem is with using TI's Code Composer Studio, which is based on Eclipse Kepler, to try to debug a unit test executable that is created with a hand written makefile from the shell. Downloading Eclipse Kepler and using a simple hello world program is to strip the problem down to basics. I run into the same problems with CCS or regular Eclipse.
The problem is, when I try to run this debug configuration, this is what the gdb traces console shows me:
290,997 2-gdb-set breakpoint pending on
290,999 2^done
290,999 (gdb)
290,999 3-gdb-set detach-on-fork on
291,000 3^done
291,000 (gdb)
291,000 4-enable-pretty-printing
291,001 4^done
291,001 (gdb)
291,001 5-gdb-set python print-stack none
291,002 5^done
291,002 (gdb)
291,002 6-gdb-set print object on
291,003 6^done
291,003 (gdb)
291,003 7-gdb-set print sevenbit-strings on
291,004 7^done
291,004 (gdb)
291,004 8-gdb-set host-charset UTF-8
291,005 8^done
291,005 (gdb)
291,005 9-gdb-set target-charset WINDOWS-1252
291,006 9^done
291,006 (gdb)
291,006 10-gdb-set target-wide-charset UTF-16
291,007 10^done
291,007 (gdb)
291,007 11source .gdbinit
291,008 &"source .gdbinit\n"
291,008 &".gdbinit: No such file or directory.\n"
291,008 11^error,msg=".gdbinit: No such file or directory."
291,009 (gdb)
291,009 12-gdb-set target-async off
291,010 12^done
291,010 (gdb)
291,010 13-gdb-set auto-solib-add on
291,011 13^done
291,011 (gdb)
291,016 14-file-exec-and-symbols --thread-group i1 C:/IntelligentD/scratch/a.exe
291,051 14^done
291,051 (gdb)
291,051 15-gdb-show --thread-group i1 language
291,052 15^done,value="auto"
291,052 (gdb)
291,052 16-gdb-set --thread-group i1 language c
291,053 16^done
291,053 (gdb)
291,053 17-data-evaluate-expression --thread-group i1 "sizeof (void*)"
291,054 17^done,value="8"
291,054 (gdb)
291,054 18-gdb-set --thread-group i1 language auto
291,055 18^done
291,055 (gdb)
291,055 19-interpreter-exec --thread-group i1 console "show endian"
291,056 ~"The target endianness is set automatically (currently little endian)\n"
291,056 19^done
291,056 (gdb)
291,057 20-break-insert --thread-group i1 -t -f main
291,058 20^done,bkpt= {number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000001004010dd",\ func="main",file="hello.c",fullname="/cygdrive/c/IntelligentD/scratch/hello.c",line="5",thread-group\ s=["i1"],times="0",original-location="main"}
291,059 (gdb)
291,060 21-exec-run --thread-group i1
291,075 =thread-group-started,id="i1",pid="10376"
291,077 22-list-thread-groups --available
291,077 =thread-created,id="1",group-id="i1"
291,077 ~"[New Thread 10376.0x22c8]\n"
291,077 21^running
291,077 *running,thread-id="all"
291,077 (gdb)
291,080 =thread-exited,id="1",group-id="i1"
291,080 =thread-group-exited,id="i1"
291,080 21^error,msg="During startup program exited with code 0xc0000135."
291,080 (gdb)
291,080 22^error,msg="Can not fetch data now."
291,080 (gdb)
291,088 23-gdb-exit
291,090 23^exit
Following some advice I read, at the command line I started gdb with: gdb --interpreter=mi a.exe and entered the same commands that show up in the log. When I get to command 21 I get different output:
(gdb) 21-exec-run --thread-group i1 =thread-group-started,id="i1",pid="7244" =thread-created,id="1",group-id="i1" ~"[New Thread 7244.0xca4]\n" 21^running *running,thread-id="all" (gdb) =library-loaded,id="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",target-name="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",host-name="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",symbols-loaded="0",thread-group="i1" =library-loaded,id="/cygdrive/c/WINDOWS/system32/kernel32.dll",target-name="/cygdrive/c/WINDOWS/system32/kernel32.dll",host-name="/cygdrive/c/WINDOWS/system32/kernel32.dll",symbols-loaded="0",thread-group="i1" =library-loaded,id="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",target-name="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",host-name="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",symbols-loaded="0",thread-group="i1" =library-loaded,id="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",target-name="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",host-name="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",symbols-loaded="0",thread-group="i1" =library-loaded,id="/usr/bin/cygwin1.dll",target-name="/usr/bin/cygwin1.dll",host-name="/usr/bin/cygwin1.dll",symbols-loaded="0",thread-group="i1" =library-loaded,id="/cygdrive/c/WINDOWS/system32/psapi.dll",target-name="/cygdrive/c/WINDOWS/system32/psapi.dll",host-name="/cygdrive/c/WINDOWS/system32/psapi.dll",symbols-loaded="0",thread-group="i1" =thread-created,id="2",group-id="i1" ~"[New Thread 7244.0x1ba8]\n" *running,thread-id="all" =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000001004010dd",func="main",file="hello.c",fullname="/cygdrive/c/scratch/hello.c",line="5",thread-groups=["i1"],times="1",original-location="main"} ~"\nTemporary breakpoint " ~"1, main () at hello.c:5\n" ~"5\t printf(\"Hello world\n\");\n" *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x00000001004010dd",func="main",args=[],file="hello.c",fullname="/cygdrive/c/scratch/hello.c",line="5"},thread-id="1",stopped-threads="all" =breakpoint-deleted,id="1"
(gdb)
Does this mean there's a bug in how Eclipse Kepler interacts with gdb? I don't know what this means, or where to go from here.
