-2

I have one C++ program with two versions, one version the feature is working but in other isn't. Is there a way to debug the difference between this two versions? Specifically, I'm using Linux and g++. Is there a way to use something like KCachegrind to view the difference Call graph? Or is something in gdb to view these function calls difference in a faster way?

Updating... The program is to big to view all the differences. Firstly i would like to know the path between function calls difference to after that i will have an option to do a diff command just in this functions.

Mauro
  • 237
  • 6
  • 13
  • 3
    Can't you use your revision control tool to diff the source code? – johnsyweb Feb 06 '13 at 21:46
  • 1
    if you can't tell the difference by looking at the source code, you probably should take a fresh start ;-) – stefan Feb 06 '13 at 21:50
  • @stefan you're correct, but i don't have this option. – Mauro Feb 06 '13 at 22:13
  • I think you're taking the wrong approach. You need to establish **why** the feature is not working in version 'B', the source from version 'A' **may** help you solve it, but essentially you should move to a working version 'C'. – johnsyweb Feb 06 '13 at 22:14
  • The difference between this versions is very big and I would like to know the difference in function call list firstly and after that use diff program to understand the difference just in this functions – Mauro Feb 06 '13 at 22:24

3 Answers3

2

What I would recommend is writing the simplest working test input that cause a failure with the new version but succeed with the previous version. Once you have this test case, build intermediate version from the different intermediate commits in your source repository (I'd suggest doing a binary search to limit the number of recompilation, git bisect is a great tool if you happen to use git).

Once you've isolated the offending commit, have a closer look at it, or if necessary use a debugger to trace your code with your test input. Hopefully, you should have ended up with a relatively small change to validate.

Sylvain Defresne
  • 42,429
  • 12
  • 75
  • 85
  • This is correct and I usually use this approach, but this code doesn't have a repository, so git bisect is useless. I just have two source codes, one for each version and no control between this versions. – Mauro Feb 06 '13 at 22:59
1

the closest you are going to get to this using gdb is using multi-process debugging[1] with some custom gdb and python scripts there is at least one such example of using gdb in this way[2]

I think it unlikely to work how you want as is. Though If you are determined to use gdb in this way it might give you some ideas.

[1] http://sourceware.org/gdb/current/onlinedocs/gdb/Inferiors-and-Programs.html#Inferiors-and-Programs

[2] http://gitorious.org/misc-gdb-stuff/misc-gdb-stuff/trees/master/misc_gdb/lockstep

matt
  • 5,364
  • 1
  • 25
  • 25
1

Have you considered using gprof? Once you have it installed (I believe most majors distros have it by default) compile your code with the '-pg' option. When you run your executable, it will generate a gmon.out file that contains profiling information including a call graph.

Have a look at this tutorial to get a better idea of how it works.

dani
  • 237
  • 3
  • 7