Richard, Thanks for the info... I'll try it out - I'm assuming that what you get out of this is very similar to what you get out of dtrace when you instrument a pid on entry and return.. Having a full trace is very helpful in tracking things down.
I'd like to go further in c code even than what I have right now, something I really can't do without a 'true' solution.. In perl, I've implemented reverse watch points - such that you give the environment a certain data sequence/ascii string, and it monitors all assignments and prints out the point in the code where they were done, the variable that was set, and the values it was set to. It does this by parsing the code for assignments, and then comparing the variable to the value(s) given by the user. I suppose I could do the same thing with my hack that does tracing, by realizing that an assignment is occuring, keeping track of the variable types of the code that I'm instrumenting, and defining a different macro for each type of assignment, but I'm coming awful close to writing a parser for c/c++ at that point and I don't think the structure I've built would support it.. Which is too bad, because that is doubly helpful (above and beyond a simple trace) for programs that you do not know. You see the behavior of the program in the form of strings being output, but don't know the structure, etc. so you poke and prod it by setting the reverse watchpoint to a string you know is going to be output, run it, get the variable name you should be looking at, and trace the stack back to the point where you are interested... How easy this would be to do even with the support of gcc/g++ is questionable, but it would be a killer function for debugging programs. With reverse tracepoints, I can typically get to perl problems 10 times faster than I can without them, especially with more complicated structures with huge object hierarchies.. Ed On Fri, Oct 31, 2008 at 3:57 AM, Richard Guenther <[EMAIL PROTECTED]> wrote: > On Fri, Oct 31, 2008 at 10:18 AM, wuxi <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] wrote: >>> >>> have a look at the flag -finstrument-functions for gcc. >> >> as far as I know, this could only record at function entry and return ? >> >> but sometimes recording all the "trace" of how program behaves is useful for >> debugging purpose. >> >> further, using a binary instrumentation tool like PIN could only record the >> low level instruction trace.... > > I would suggest to do the instrumentation in the frontends as there > you still know > the original statement boundaries. Note that the original program text may be > not readily available there, so you might need to hack libcpp as well. > > Richard. >
