ok, wrt the below, I was giving it some thought, and was wondering how usable the gcc lexer/parser combo was by itself, how 'pluggable' it was - my hope was that I could take the lexer/parser and instead of making an executable out of the incoming code, I could transform the code in place, ie: add extra code of my own choosing that I would then compile with gcc.
How feasible would that be? Where's a good place to start? Thanks, Ed On Fri, Oct 31, 2008 at 11:24 AM, Edward Peschko <[EMAIL PROTECTED]> wrote: > 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. >> >
