I have a situation in which I'm remotely debugging an application which uses a static library. Both the static library and the application are built with the -g flag, and there are debug entries shown on objdump -t lib.a | grep debug.
However, the debugger only stops the breakpoints in the functions of the main application, but ignores the ones in the static lib. I do a print statement in the lib which gets executed but a breakpoint on the same place is ignored. The lib source is also available. I'm using Qt creator for the debugging interface.
My question is if there is a way to debug this setup? Can gdb print some log messages at run time that could point to the error?
what does it say when you set the breakpoint? type:
info b
and see if your breakpoints are enabled. If you have optimization enabled, the code that you refer to may be optimized out.
Related
I'm working on a project, where I cannot disclose the details of the code. So, the application is all written in C and C++. Since, a particular file which wanted to debug has a lot of dependencies and exports, I need to debug the whole project. How do I set breakpoints in the code itself so that the debugging would stop at that particular point? I'm using Ubuntu 14.04 (since the project is compatible with this environment) and gdb debugger.
I've tried using
#include <csignal>
// Generate an interrupt
std::raise(SIGINT);
But I keep getting error
error: ‘raise’ is not a member of ‘std’
Even this also didn't work
#include <signal.h>
raise(SIGINT);
Plus the debugging wont stop at that point, so that I could foresee the function at that point. I only want to debug it from console, rather using any IDE.
Since the programfile I want to debug has lot many header files which it imports, I'm unable to make a executable to use gdb. So, while make clean build of my MakeFile I want to debug the particular program file at a particular function. So, for that I want to add breakpoints in the program. I cannot use any GUI for debugging since I should not use.
Have you tried to use GDB Commands?
b lineno - set a break point at line 'lineno'
b srcfile:lineno - set a break point in source file 'srcfile' at line 'lineno'
Read more about debugging with gdb. Be sure to compile all your code with DWARF debug information (so use g++ -Wall -Wextra -g to compile it with GCC).
GDB is extensible and you can define your own gdb commands at startup in your init file, probably .gdbinit and put some initial commands there.
BTW, on Linux, debugging (so the gdb debugger) is using ptrace(2) facilities. And you can use gdb non-interactively on the command line, using scripts.
How do I set breakpoints in the code itself
I don't recommend adding specific C code for breakpoints. So don't do that in your C code. But see also this.
Perhaps you want some backtrace library, like Ian Taylor's libbacktrace ?
I cannot use any GUI for debugging
You don't need to. You'll use gdb on the command line. With an appropriate gdb script, you can even use it non-interactively (e.g. in a Makefile)
I only want to debug it from console, rather using any IDE.
Please realize that IDEs are only glorified source code editors capable of running other external tools (including the GCC compiler and the gdb debugger). You certainly don't need -on Linux- any IDE to run a compiler or a debugger (but IDEs could be convenient, but not necessary, for that), because you can (and should) run your compiler, your debugger, your build automation tool, on the command line.
Since the program file I want to debug has lot many header files which it imports, I'm unable to make a executable
You should fix that first. You need to make an executable. BTW, there is no "import" involved at run time, since header files are relevant only at compile time. Read more about the cpp preprocessor. You probably should invoke GCC (e.g. the g++ compiler, since you have C++ code) with appropriate preprocessor options (sometimes, tools like pkg-config are useful for that). You probably should use some build automation tool such as GNU make (with your Makefile; see this for inspiration) or ninja. You could add ad hoc gdb commands to your build procedure (e.g. with some additional and specific rules and/or recipes in your Makefile).
First, make sure you have compiled with -g. There are other gdb specific flags in gcc. You could add them in too.
Try using ddd, the graphical version of gdb. Great tool if you don't know the gdb command line. Just open up the relevant source file, select the line then click on breakpoint on the toolbar. It will tell you on the console section, what command was actually executed (good way to learn). There is a floating button list with run, next etc. for stepping through your code.
ddd will work on most of the gcc toolchain.
EDIT:
Say your code is made up of 2 files main.cpp and child.cpp. main.cpp contains main(). The executable is called a.out.
To start
ddd a.out &
It will open in main.cpp. To put a breakpoint in child.cpp, click on File/Open Source... and select child.cpp. Then scroll to where you want a breakpoint. Put your cursor on the line, then click on break in the toolbar.
To run, either type run in the gdb window below or click on Run in the floating button dialog.
Linux system running an application. This application is a cpp binary without any debug symbols. Some how this application using 100% cpu. Would like to debug why it is running infinitely. If I stop and replace the binary with debug symbols, the issue may not be reproducible.
So, running the same application with debug symbols in another environment. Here it is running fine.
Can I compare them (with and without debug symbols binaries) and deduct what is the problem using GDB.
This application is a cpp binary without any debug symbols
You don't need any debug symbols to understand where it is spending time, you just need the application to not be fully-stripped (most binaries aren't).
Use perf record -p $pid to collect CPU profile, then perf report to analyse it.
If the application is fully stripped, you can still use perf record to collect program counter values, then perf record --symfs ... to point it to unstripped copy of the application. Documentation here.
Beware: both stripped and unstripped copies must be built with exactly the same build flags, or you'll get garbage. Best practice is to always save unstripped copy as part of the build process.
Recently, our development team is starting to use ccache to do faster compile (the compile is done from sandbox /usr/x).
Now, when I compile from my sandbox (/usr/y), and try to set a breakpoint in the code in Eclipse (GDB (DSF) process launcher), it fails to find the file.
Further investigation shows that Eclipse gdb uses the complete path of the file to set a breakpoint (e.g. b /usr/y/untouchedFile.cpp:1234), but the actual path (in the gdb debugger) is actually /usr/x/untouchedFile.cpp.
The only thing that works is to set a breakpoint on the console by typing it, and do a source file mapping when the breakpoint is hit.
I would like to set the breakpoint by clicking on the code line (which used to work before ccache).
I was wondering if there is a way to get around this.
Thanks!
I am trying to debug, with gdb, a plugin to a program. I saw a question earlier that indicated that the directory command in gdb might help. I thought it would help because, when I try to set a breakpoint within the code of the plugin, I get the error that says: "No source file named..." It didn't seem to do anything when I used the directory command with the source path structure. Any ideas? Thanks.
"No source file named..."
GDB will not be able to set a breakpoint until your plugin is actually loaded into the inferior (being debugged) process.
Use (gdb) info shared command to check whether your plugin is already loaded or not.
If it isn't, you can set a "deferred" breakpoint (GDB should be asking you whether you want to set such a breakpoint, assuming you have the default set confirm on setting).
If your plugin is already loaded and visible in info shared output, then you haven't built your plugin with debug info. Rebuild it with -g, and you should be able to set breakpoints in it.
I am an experienced Visual Studio developer who has recently taken on an OSX 10.6 project (a C++ server project with no UI).
I have been successfully debugging the application using the XCode debugger (setting breakpoints, etc.) for months, including debugging the source code for various static libraries that are linked into the final executable program.
However, tonight I was required to debug (with breakpoints) a DYLIB that is also built from our source code, but that is linked dynamically at runtime with the application (the name of the DYLIB is read from an .ini file by the main application).
Unfortunately, the usual method I use of debugging the application (right-clicking the custom executable and selecting "Debug with Breakpoints"), though it does successfully run the debugger and allow me to debug the application (along with its statically linked libraries), exhibits the following undesired behavior when I attempt to hit a breakpoint in the source code for the DYLIB:
-> The XCode debugger reports that the breakpoint was hit in the sense that I see the function and line number in the status bar at the bottom of the XCode windows (along with an indication that this is a gdb message), and the application halts execution. However, there is no stack trace, no variables, nothing - just a completely empty debugger window. The buttons to to "step over", "step into", etc, are disabled. No editor window appears in the debugger (and hence no visual indication that the debugger has stopped on the line indicated). Opening the file by hand does not reveal the debugger hitting the line.
Unfortunately, this is useless for me as far as my attempts to debug the DYLIB.
I have hunted far and wide tonight researching and attempting to find a way for the XCode debugger to successfully hit breakpoints in a meaningful way in the source code for this dynamically linked DYLIB. I have of course done a number of clean/rebuilds. I have made certain that "load symbols lazily" is unchecked and then cleaned/rebuilt. I have restarted, and I have also deleted the "build" directory and rebuilt. I also deleted the user-specific files in the .xcodeproj package. (Note also that I am of course building and running all code, including the DYLIB code, in Development mode with all optimizations off, and generating debug symbols for all.) However, my attempts have been unsuccessful. Nor can I find so much as a single mention of this problem on internet forums.
Any help in instructing me how to use XCode to successfully debug a DYLIB that is linked to my application would be appreciated.
Thanks,
Dan.
Update -
This problem is resolved. It was my lack of experience with OSX that caused me to fail to see this. Despite the fact that my DYLIB project was part of the same XCode project as the executable that calls it, and despite the fact that the DYLIB was built in the same directory as the executable, at runtime the debugged application was not accessing the DYLIB from this location. Instead, it was accessing it from a (different) install location. I have not as of this moment tracked down where the install location is "cooked" into the application, but by copying the final executable/DYLIB into the expected install location and creating a new custom executable that points to the executable in this location, debugging of both the DYLIB and the executable works.
Thanks,
Dan.