2

I'm working on the rewriting of some code in a c++ cmd line program.

I changed the low level data structure that it uses and the new version passes all the tests (quite a lot) without any problem and I get the correct output from both the new and the old version... Still, when give certain input, they give different behaviour.

Getting to the point: Being somewhat of a big project I don't have a clue about how to track down when the execution flow diverges, so... is there way to trace the function call tree (possibly excluding std calls) along with, i don't know, line number in the source file and source name? Maybe some gcc or macro kungfu?

I would need a Linux solution since that's where the program runs.

Fred
  • 4,894
  • 1
  • 31
  • 48
3mpty
  • 506
  • 1
  • 6
  • 14
  • Are you asking for a way to print the call stack when control reaches a certain point (i.e. adding code to output the current stack), or are you looking for an external tool to analyze your program flow as it runs (basically callgrind's manpage)? – Fred Nov 21 '12 at 15:49
  • I've used callgrind before, but, if I remember, it only outputs the number of time a function gets called and the relationships between functions (and other stuff too, but it discards the program history). I could well be wrong since I only used it through KCachegrind. I need something that "simply" outputs function names and where they are called from as the execution flows. Like ltrace but for my code, not library calls. – 3mpty Nov 21 '12 at 16:35

1 Answers1

0

Still, when give certain input, they give different behaviour

I would expand logging in you old and new versions in order to understand better work of your algorithms for certain input. When it become clearer you can for example use gdb if you still need it.

Update

OK, As for me logging is OK, but you do not want to add it.

Another method is tracing. Actually I used it only on Solaris but I see that it exists also on Linux. I have not used it on Linux so it is just an idea that you can test.

You can use SystemTap

User-Space Probing
SystemTap initially focused on kernel-space probing. However, there are many instances where userspace probing can help diagnose a problem. SystemTap 0.6 added support to allow probing userspace processes. SystemTap includes support for probing the entry into and return from a function in user-space processes, probing predefined markers in user-space code, and monitoring user-process events.

I can gurantee that it will work but why don't give it a try?

There is even an example in the doc:

If you want to see how the function xmalloc function is being called by the command ls, you could use the user-space backtrack functions to provide that information.

stap -d /bin/ls --ldd \
-e 'probe process("ls").function("xmalloc") {print_ustack(ubacktrace())}' \
-c "ls /"
  • I thought about that, but I just can't go here and there adding logging messages throughout the code. – 3mpty Nov 21 '12 at 16:51
  • @3mpty, these "user space probes" are based on software breakpoints. You just need to build your program with debug info and provide a white or black list of function names. – scottt Nov 22 '12 at 11:04
  • Thanks :) I got a basic trace log using the simple stuff at https://github.com/creechley/etrace but it's more an hack than something serious I'll try systemtrap to see if I can get better results. – 3mpty Nov 22 '12 at 16:35