0

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.

blue scorpion
  • 387
  • 1
  • 10
  • `gdb` is scriptable in Python. Read about [extending `gdb`](https://sourceware.org/gdb/current/onlinedocs/gdb/Extending-GDB.html). So you might work on scripts achieving your goal. – Basile Starynkevitch Nov 09 '18 at 01:29
  • 2
    Would [gcov](https://gcc.gnu.org/onlinedocs/gcc/Gcov.html) do what you want? It's a code coverage tool, so you could run it once with the working input, then run it again with the non-working input and compare the output. – user1118321 Nov 09 '18 at 04:15
  • Thanks, user1118321, I tested that on a simple example. Seems to work. – blue scorpion Nov 09 '18 at 21:20
  • 2
    Related: [How to record instruction history and function call history in gdb](https://stackoverflow.com/questions/22507169/how-to-run-record-instruction-history-and-function-call-history-in-gdb) – Mark Plotnick Nov 10 '18 at 09:43
  • Interesting, Mark Plotnick. I couldn't get it to run, yet. It seems I have (most of) the right ingredients: gdb version 7.11, kernel version > 4.6 (4.15.0-36-generic), intel_pt. But something is still missing (gdb error: "GDB does not support Intel Processor Trace."). I need to dig deeper for this one. But definitely worth trying. – blue scorpion Nov 12 '18 at 22:09

1 Answers1

0

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.

blue scorpion
  • 387
  • 1
  • 10