I use Goland ssh to write code. I fail to use debug mode in my project, the breakpoints turn into gray crossed circles and report error "executable doesn't containt debug information".
The error information is here.
This is the Run/Debug Configuration of my project
However, I still could use debug mode and set normal breakpoints in Testing file.
I met exactly the same problem just now.
Finally I find the reason is the function which I set breakpoint doesn't been called in the repo.
It's called by another repo, so compile and debug the repo that call this function can solve this problem.
The error "error layer=debugger error loading binary "/lib/x86_64-linux-gnu/libpthread.so.0": could not parse .eh_frame section: pointer encoding not supported 0x9b at 0x12e8" still exists, but the breakpoints won't turn into gray crossed circles.
please see this https://youtrack.jetbrains.com/issue/GO-13005 .
Next 2022.2 nightly build bundles delve which doesn't produce an error.
On my fedora box I have installed a lot of separate debug infos.
sudo dnf debuginfo-install <list of packets>
Now, if I debug some simple code it needs very long until some symbol is displayed or some values are printed. It is quite clear that is absolutly needed to evaluate all the installed symbol files to get all information.
But if I have a problem, say on a lib like goocanvas I only want to have my local debug smbols generated with my own compiled code with -g option and the only the debug infos for goocanvas libs.
How can that kind of selection be achieved? Only by renaming the folder of debug info files and generate a copy of needed ones? Maybe as a symlink? Or is there a common selection option anywhere?
You can skip all debug info from shared libraries and only load goocanvas lib symbols. Here is a sample of how to do it in gdb session:
[ ~]$ gdb -q /your/binary
(gdb) set auto-solib-add off
(gdb) start
Temporary breakpoint 1, 0x000055555564edd0 in main ()
(gdb) sharedlibrary goocanvas
From gdb doc:
If your program uses lots of shared libraries with debug info that
takes large amounts of memory, you can decrease the gdb memory
footprint by preventing it from automatically loading the symbols from
shared libraries. To that end, type set auto-solib-add off before
running the inferior, then load each library whose debug symbols you
do need with sharedlibrary regexp, where regexp is a regular
expression that matches the libraries whose symbols you want to be
loaded.
See also this related question: How to prevent GDB from loading debugging symbol for a (large) library?
I'm new to golang. I was debugging my go application.
While I tried to run "info goroutines", it threw out:
Undefined info command: "goroutines".
Try "help info
What did I miss in my gdb configuration?
The article "Debugging Go Code with GDB" does mention:
(gdb) info goroutines
But only in the context of loading extension scripts for a given binary.
The tool chain uses this to extend GDB with a handful of commands to inspect internals of the runtime code (such as goroutines) and to pretty print the built-in map, slice and channel types.
If you'd like to see how this works, or want to extend it, take a look at src/pkg/runtime/runtime-gdb.py in the Go source distribution.
It depends on some special magic types (hash<T,U>) and variables (runtime.m and runtime.g) that the linker (src/cmd/ld/dwarf.c) ensures are described in the DWARF code.
If you're interested in what the debugging information looks like, run 'objdump -W 6.out' and browse through the .debug_* sections.
So make sure your debug session is run with those extensions activated.
in the gdb session run
source $GOROOT/src/runtime/runtime-gdb.py
where $GOROOT is go lives (see go env | grep ROOT)
you should use https://github.com/go-delve/delve as recommended by golang docs https://golang.org/doc/gdb
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.
Answering my own question because I figured it out through much trial and error, and it didn't involve mucking with gdb-mi.
In short, I found no way to have Eclipse debug an executable that is not associated with an existing project. I had to create a new project of type "Makefile project with existing code" with this new project's home directory somewhere that does not already have the .project and .cproject files, in my case a subdirectory of my original cross-compiled project which is a CCS project. Then, in the new Eclipse project's debug configuration, point it to where to find the source code.
Eventually I got this working in Code Composer Studio. The full explanation is the last post I made in this thread: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/p/375037/1323811.aspx#1323811
I'm not including the full explanation in this answer because my question here is about regular Eclipse, while the answer is about the CCS IDE.
I have a Makefile-powered project in Visual Studio 2010 (uses NAnt, in fact, but that's beside the point).
The output of the build process is a .elf file, and I have a separate, non-VStudio debugger which can be run on that .elf file to debug it.
Building works fine, but when I click the 'debug' button (little green triangle), VStudio fails with "Unable to start program 'XXX.elf'. The specified file is an unrecognized or unsupported binary format"
I'm guessing VStudio is just trying to 'run' the .elf as though it were an .exe, and failing.
What I really want VStudio to do is run "my_debugger.exe XXX.elf" when I press the debug button.
I have tried adding a file association with .elf=>my_debugger.exe
I have updated PATHEXT appropriately as well, and run VStudio under those changes.
Still no luck.
Isn't there somewhere in VStudio where you can specify a custom debug command? I thought there was, but can't find it.
I could just have the build process output a .bat file or something I guess, but this seems silly.
As Jim mentioned you can specify which app to start on run in the project settings (Command field). If you place a debugger there you can pass down your executable as an argument to the debugger being launched (Command Arguments field). This way you can launch the debugger which in turn will launch your executable if the debugger expects any commandline arguments.
MinGW on Windows example:
Command: gdb.exe; Command Arguments: Path\ToMyApp\whatever.exe
will start gdb.exe, gdb.exe will open whatever.exe, parse the debug info and wait for debug instructions.
Command: msys.exe; Command Arguments: gdb.exe Path\ToMyApp\whatever.exe
will start msys.exe, msys.exe will execute "gdb.exe Path\ToMyApp\whatever.exe"
Look at the project properties. Do you have a Debug tab which has a Start Action section giving three choices? Those choices would be: ( ) Start project, (x) Start external program: ... ( ) Start browser with URL.
You can also set the command line arguments and working directory.
Cf. How to: Change the Start Action for Application Debugging