This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 'recording' program execution.


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
<richard.guenther@gmail.com> wrote:
> On Fri, Oct 31, 2008 at 10:18 AM, wuxi <wu.andrew.xi@gmail.com> wrote:
>> muenchen@physik.uni-wuppertal.de 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.
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]