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?
My problem is the following: An application (namely eclipse) crashes on my machine, and shows the following error message:
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 16911 error_code 3 request_code 3 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Now what I want to do is to actually run gdb as suggested by the error message. However, I didn't succeed and no backtrace is displayed.
I haven't much experiences with debugging. Here is what I tried anyway:
1) Activate -dbgsym repositories
2) Install eclipse dbg symbols (command sudo apt-get install ^eclipse-.*dbgsym)
3) Install libgtk-3-0-dbg, libgtk2.0-0-dbg and all packages matched by ^libgdk.*dbg
4) Run gdb:
(gdb) file /usr/lib/eclipse/eclipse
Reading symbols from /usr/lib/eclipse/eclipse...
Reading symbols from /usr/lib/debug/.build-
id/c2/8e5f4ebdd67159093d8ee6e6daf58ab6fab94c.debug...done.
done.
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
(gdb) run --sync
[Update] I also tried the following (without success):
1) - 3) same as above
4) Run gdb:
(gdb) file /usr/lib/eclipse/eclipse
Reading symbols from /usr/lib/eclipse/eclipse...
Reading symbols from /usr/lib/debug/.build-
id/c2/8e5f4ebdd67159093d8ee6e6daf58ab6fab94c.debug...done.
done.
(gdb) break main
Breakpoint 1 at 0x4010a0: file ../eclipseMain.c, line 101.
(gdb) run --sync
Starting program: /usr/lib/eclipse/eclipse --sync
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdf18) at ../eclipseMain.c:101
101 ../eclipseMain.c: file or directory not found.
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
(gdb) cont
[/Update]
Result:
When the application crashes, the output is the same as above, no additional info is displayed. I assume that my approach is wrong, or I've loaded the wrong debug symbols. (Because it says "gdk_x_error" not defined.)
[Update2]
When I type bt after the crash, it shows me No Stack.
[/Update2]
What can I do to get a meaningful backtrace? Any ideas?
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.