Are there any debuggers, tools, gdb-scripts that can be used to do code-path analysis?
Say I have an executable (in C++, but the question is not language restricted) that runs fine with one input and crashes with another. I would like to see the difference between the two execution paths, without having to step (or instrument) through potentially thousands of lines of code.
Ideally, I would be able to compare between 2 different streams of (C++) statements (preferably not assembler) and pinpoint the difference(s). Maybe a certain if-branch is taken in one execution and not the other, etc.
Is there a way to achieve / automate that? Thanks in advance.
So, provided the source of the bug could be located in one (or a few) source files, the simplest way to achieve comparative code-execution paths seems to be GDB scripting. You create a gdb script file:
set args <arg_list>
set logging off
set logging file <log_file_1>
set logging on
set pagination off
set breakpoint pending on
b <source_file>:<line_1>
commands
frame
c
end
...
b <source_file>:<line_n>
commands
frame
c
end
with a preamble (all the set commands) and then breakpoint + command for each line in the source file (which can be easily generated by a script; don't worry about blank or commented lines, they will be skipped).
Load the executable in gdb (properly built with debug flags, of course); source the gdb script file above (call it gdb_script.txt) and run:
source gdb_script.txt
run
Then repeat the process above with a slightly changed script file (gdb_script.txt). Specifically, change the <arg_list> to modify the input; and set logging file to a different file <log_file_2>.
Source and run. Then compare <log_file_1> vs. <log_file_2> with your preferred diffing tool (say, tkdiff).
This will not do a better job than gcov (suggested above). But, it can help better restrict your output to the suspicious region of code.
Related
I am dealing with a large code base with tons of globals. Under some peculiar set of data it produces the wrong result. I wanted to automatically run few scenarios with gdb in automatic step-by-step execution and periodical dumping
of some values and recording the tracing in some file. Doing it manually will ruin my sight and my brain. I speculate that there is some globals mess-up. How to do this automatically? Use some scripting. All this is in RH linux.
Thanks in advance.
tried to do this manually using conditional breaks, but gave up after a while
I wanted to automatically run few scenarios with gdb in automatic step-by-step execution and periodical dumping of some values and recording the tracing in some file.
It may be significantly more effective to run the program under reverse debugger (such as rr), and trace the wrong result back to its source.
How to do this automatically?
You can't do automatically what you can't express as an algorithm, and you haven't described an algorithm you want to use. If it's something like "stop every 100 times foo is called and print the values of these 500 globals", than that's trivially automatable with GDB.
More complicated algorithms are possible with the use of embedded Python.
In the .gdbinit file in your home folder add
add-auto-load-safe-path /path_to_the_folder_containing_your_executable/
Now you can create another .gdbinit file in the same folder where your executable is that will be loaded when you start gdb from there (the .gdbinit file in your home that is also read - useful if you have nice stuff there such as loading pretty printers).
In this .gdbinit file, add the code below
file your_executable_name
start
# Optional
set args "<any command line parameters you program might need>"
# xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Add gdb commands below to set breakpoints, print variable values, etc
# xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
run
Gdb is very powerful and I'll list a few things that might help this automation.
You can set breakpoints with b filename.ext:line_number or b function_name
You can use commands breakpoint_number (see here) and then list commands that should be run after this breakpoint is hit. Use end to finish the commands
You know the breakpoint number, since they are created sequencially (note that the start will count as a breakpoint and thus the first one you add will be breakpoint 2)
You can use convenience variables to store useful things such as the address of an important object
The python api is very powerful
One idea is that you can save the address of the important global variables (if they are not always accessible) using convenience variables. For instance, add a breakpoint where this global variable is and then add to this breakpoint the command to save the address of this variable to a convenience variable followed by continue (with continue you will not see gdb stopping there).
set $var1 = &myglobal
continue
You might want to also delete this breakpoint with delete breakpoint_number before continue to avoid stopping at this breakpoint again.
Then as long is the object exists you can inspect it using p $var1 or p $var1->something when the program is stopped at a different breakpoint where myglobal might not be directly accessible.
In the commands that you add to be run when a breakpoint is hit you can do things such as echo message explaining where you are, p some_var to see the values of variables or even python some_complicated_python_code.
In the case you want to use python for more power it is worth reading the section about it in the manual. Let-me give you one example. Suppose one of your global variables was stored in a convenience variable called "$myvar". Then you can pass it to the python interpreter with
python myvar = gdb.parse_and_eval("$myvar")
You can also pass any variable in the current scope to parse_and_eval.
Now, suppose this global variable stores an object of a class with a "n_elem" attribute you want to check. You can print it with
python print(myvar["n_elem"])
You can also create a python file in the same folder and use
python from my_python_file import *
to import functions defined there.
With these gdb features you can pretty much automate whatever you might need.
after searching for hours on the internet I could not find any information or documentation about this. Does anyone know if there is a way to get this done?
Would be great to get a hint to the right direction.
Thanks in advance,
Alex
You have to write task that will use file tracking for incremental build.
.NET API seems is here: FileTracker Class
If I were you I’d try to disassemble Microsoft.Build.CPPTasks.Common.dll assembly - class Microsoft.Build.CPPTasks.TrackedVCToolTask to get an idea how it works.
So here’s my off-the-cuff idea how it can works:
I think Tracer.exe starts child process (your tool as suspended process).
Then it patches kernel32.dll file winapi to track all read and write operation (so I think they patches CreateFile and CloseHandle).
Then resumes process
After process is finished you should get list of files the child process used.
Write file list of input file that were used to produce output file into log file.
Second time is yout task invoked you can make optimization in build. Because you have file mapping now you should be able decide if you call your tool for given output or you skip it. You can skip it in case output file time-stamp is newer then all input files and none setting for compilation has changed (project file time-stamp - or something more sophisticated).
File Tracking
I'm adding some features I find useful to my GDB startup script. A few of the startup commands apply only to "live" targets, or have components that make sense only with live targets. I'd like to be able to test for the presence (or absence) of a core file, and skip or amend these commands as appropriate.
I looked around in the Python API, but couldn't find anything that tells me whether an inferior is a core file or a live program. I'm fine with a scripting solution that works in either GDB itself or in the Python GDB scripting interface.
It doesn't look like there is a way to do that.
I'd expect an attribute on gdb.Inferior, but there isn't one.
File a feature request in GDB bugzilla.
info proc status returns "unable to handle request" for core files, whereas for a live process it returns several lines, the first of which looks like: "process 1234".
You can run that command and compare its first output line against that string using the execute_output() function from here: https://github.com/crossbowerbt/GDB-Python-Utils/blob/master/gdb_utils.py
Is there a way to set a breakpoint at every line in the code with GDB? Obviously I don't want to hit b *addr for every single line, so I'm wondering if there's a fast way to do this.
Edit
Note that I am running a binary created by someone else and I do not have access to the source code. Unfortunately, that binary has not been compiled with the -g flag. Therefore, I cannot just single step through each line in the code.
Further Edit
As Jason points out below, you can indeed single step through the code so long as you use si or ni, as opposed to just simply s (step) or n (next). n or s work fine, though, if the source code had been compiled with -g, but it steps through lines of source code, as opposed to stepping through every assembly instruction like ni or si do in a binary that was compiled without -g.
Use si (stepi) to instruction step through the code. You can use ni (nexti) to step over library functions you're not interested in. If you accidentally step into one of them, finish should get you back to your original routine. People working at this level typically have gdb set to display the next few instructions that are about to be executed, e.g. disp/3i $pc.
Can't you just place the breakpoint on the first line of execution and then step through each line ? This depends on what are you trying to achieve by setting breakpoints on each line. If you want to evaluate expressions, you can do it by following my logic (step through each line).
PowerPC has hardware support for ranged breakpoints, and GCB offers:
break-range start end
in that arch. So I think you could just break on the entire memory address, or the entire text section (untested).
The command fails on x86.
Doc: https://sourceware.org/gdb/onlinedocs/gdb.html#index-break_002drange-1548
I know the answer to this, I'm putting it up here for others to see it
If you use eclipse CDT, you probably understand that eclipse isn't a debugger, it's just an application front-end, specifically to GDB. So when debugging C++ programs, you're actually just using GDB in a more comfortable manner. If you ever have to debug a multithreaded program in eclipse CDT, you'll realize that things quickly get hectic because when you hit a breakpoint, all threads stop, and when one tries to execute a single line in a specific thread, it also runs the other threads. In order for it to work properly, the threads have to be able to be run arbitrarily and exlusively-so that when the programmer executes a single line, it only executes the specific thread.
So, by default, gdb's settings by default leave the "scheduler-locking" turned off. If you debug multithreaded applications you'll understand that this must be on in GDB in order for the desired behavior to be achieved. How does one run this command:
set scheduler-locking on
in GDB within eclipse CDT?
At least one way to do it that certainly solves the problem is knowing how to navigate the immense set of features that eclipse offers. Typically, when a program starts, eclipse CDT switches the console window (if you have it open, typically it's on the bottom) to show the input/output of the program.
But you can change this if you didn't know-see this image. That button on the second to last right-the blue one that looks like a monitor-you can select the GDB input console. It was discussed also in this thread.
From there merely type the command.
SOLVED, BUT NEED A BETTER SOLUTION
But now that this has been solved, to solve it in a better way as a matter of convience; having to type set scheduler-locking on every time a program starts is silly. But the problem with loading a gdbinit file is that the gdbinit file gets sourced before eclipse has set the program for gdb to solve. This is a problem, as it causes the debugger view to hang within eclipse, as gdb complains. To understand what is happening, try and fire up gdb, then give the command without loading a binary to execute. It fails-so how does one set this as an option that is sticky?
Maybe if you add the following gdb script which could set the variable when the program stops and turns it off if you continue:
define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end
My answer is derived from the one by #user1448557 . Unfortunately, I don't currently have enough reputation to comment on it (or to upvote it by the way). The strategy seems great, but the answer might be a bit outdated because it doesn't involve "set scheduler-locking step". I have put the following in my gdb initialization file (within my Eclipse project) and it does what I want.
#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end
With regards to the comment by #rbaleksandar, Eclipse CDT launch configurations allow one to specify a "GDB Command File" and the default is usually .gdbinit