I would like to connect my compiled object code to the c++ code, and then to check if a certain line of code was executed.
How to do those two things?
If the explanation is not simple (I bet it is not), can someone at least point to some web pages explaining how to do this?
I understand that the solution is different for different platforms, but I am interested in how it is done on windows and linux (linux for the start)
If you want to know how it is done,
gdb is open source
the ptrace syscall should get you started,
libunwind-ptrace
this is a nice article using ptrace
I suspect that you don't really need a debugger but a profiler. I like the callgrind at http://valgrind.org/docs/manual/cl-manual.html, which has a nice graphical environment at http://kcachegrind.sourceforge.net/.
To try I'd use
$ valgrind --tool=callgrind ./myapp
$ kcachegrind callgrind.out.xxx
In your comment you say "I would just like to gather informations on how to check which methods/functions are executed during the execution, and how many times".
If that is what you want to achieve, then use a profiler such as gprof.
Compile your program with -g -pg and when your program finishes it will create a file which can be processed by gprof to show you what you want.
Related
I am working on a big code base. It is heavily multithreaded.
After running the linux based application for a few hours, in the end, right before reporting, the application silences. It doesn't die, it doesn't crash, it just waits there. Joins, mutexes, condition variables ... any of these can be the culprit.
If it had crashed, I would at least have a chance to find the source using debugger. But this way, I have no clue how to use what tool to find the bug. I can't even post a code sample for you. The only thing that can possibly help is to tap MANY places with cout to get a visual where the application is.
Have you been in such a situation? What do you recommend?
If you're running under Linux then just use gdb to run the program. When the application 'silences', interrupt it with CTRL+C, then type backtrace to see the call stack. With this you will find out the function where your application was blocked.
Incase of linux, gdb will be great help. Another tool that can be of great help is strace (This can also be used where there are problems with program for with source is not readily available because strace does not need recompilation to trace them.)
strace shall intercept/record system calls that are called by a process and also the signals that are received by a process. It will be able to show the order of events and all the return/resumption paths of calls. This can take you almost closer to the area of problem.
iotop, LTTng and Ftrace are few of other tools that be helpful to you in this scenario.
im using GDB to debug a C code in eclipse, and i wanted to ask a question about the GDB handling multiple commands.
if i send the GDB multiple commands through an external software for example:
im sending 'bt', and 'p counter', and than 'help'.
is it possible that the 'bt' command is taking too long to process and return an answer that the GDB will suspend the 'bt' command handling and will try to handle the next command?
it doe'snt make sense to me if it did, but it is important for me to know if it is possible.
i checked in google and i have read the gdb tutorial but never found explanation about the GDB handling commands that are sent to it.
thanks.
Check GDB Internals which talks about many important GDB operations and algorithms. If you have time it is good to dig deeper by looking at GDB source code to understand well.
I'm writing a software renderer in g++ under mingw32 in Windows 7, using NetBeans 7 as my IDE.
I've been needing to profile it of late, and this need has reached critical mass now that I'm past laying down the structure. I looked around, and to me this answer shows the most promise in being simultaneously cross-platform and keeping things simple.
The gist of that approach is that possibly the most basic (and in many ways, the most accurate) way to profile/optimise is to simply sample the stack directly every now and then by halting execution... Unfortunately, NetBeans won't pause. So I'm trying to find out how to do this sampling with gdb directly.
I don't know a great deal about gdb. What I can tell from the man pages though, is that you set breakpoints before running your executable. That doesn't help me.
Does anyone know of a simple approach to getting gdb (or other gnu tools) to either:
Sample the stack when I say so (preferable)
Take a whole bunch of samples at random intervals over a given period
...give my stated configuration?
Have you tried simply running your executable in gdb, and then just hitting ^C (Ctrl+C) when you want to interrupt it? That should drop you to gdb's prompt, where you can simply run the where command to see where you are, and then carry on execution with continue.
If you find yourself in a irrelevant thread (e.g. a looping UI thread), use thread, info threads and thread n to go to the correct one, then execute where.
I want to use valgrind to do some profiling, since it does not need re-build the program. (the program I want to profile is already build with “-g")
But valgrind(callgrind) is quite slow ... so here's what I to do:
start the server ( I want to profile that server)
kind of attach to that server
before I do some operation on server, start collect profile data
after the operation is done, end collecting profile data
analyze the profiling data.
I can do this kind of thing using sun studio on Solaris. (using dbx ). I just want to know is it possible to do the same thing using valgrind(callgrind)?
Thanks
You should look at callgrind documentation, and read about callgrind_control.
Launch your app : valgrind --tool=callgrind --instr-atstart=no your_server.x
See 1.
start collect profile data: callgrind_control -i on
end collect profile data: callgrind_control -i off
Analyze data with kcachegrind or callgrind_annotate/cg_annotate
For profiling only some function you can also find useful CALLGRIND_START_INSTRUMENTATION and CALLGRIND_STOP_INSTRUMENTATION from <valgrind/callgrind.h> header and using callgrind's --instr-atstart=no option as suggested in Doomsday's answer.
You don't say what OS - I'm assuming Linux - in which case you might want to look at oprofile (free) or Zoom (not free, but you can get an evaluation licence), both of which are sampling profilers and can profile existing code without re-compilation. Zoom is much nicer and easier to use (it has a GUI and some nice additional features), but you probably already have oprofile on your system.
I am using emacs and autotools, to write and compile c/c++ sources on linux.
I am using gdb via GUD in emacs.
I have defined for convenience: F7:compile, F10:gud-next, F11:gud-step, F5:gud-cont, F9:gud-tbreak, F8:gud-until, F4:gud-print.
I am mainly interested in debugging c/c++ source code on linux from emacs and I would like to get the most gdb can give.
Unfortunately I am using only F4 which prints the variable under cursor.
So my question is how do you guys debug the source code ?
What programs do you use ?
What key bindings (functionality) do you use mostly ?
What do you need the debugger to do for you ?
If you do weird stuff it doesn't matter. I would like to know everything to boost my speed a bit here.
Thanks in advance.
Mihai
I use the M-x gdb... commands to select the windows I need, then I use the gdb prompt.
I often set break points with C-x SPC on the source line once gdb is underway,
You'll get the most out of gdb by using the command line instead of key bindings. The most useful commands that I use:
bt - prints a backtrace; helpful to know full context of where you are
s, n, cont - step, next, continue
run - very useful for starting over within the same session
watch - sets a watchpoint; useful for catching when a value changes
call - invoke a function
display - Print a value every time the program stops.
valgrind is perfect for detecting memory errors. Most of the times you are given the exact location of where the error is.
gdb is nice too, but doesn't have great interface, so it is best to be used with some kind of gui like ddd or Eclipse for instance (yes, I am using gdb with Eclipse, it has built in support for it).
I only use the debugger to get a backtrace on a segmentation fault. For everything else I use printf debugging.