This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: C programs introspection using binutils/gdb


On Thu, Apr 01, 2004 at 03:15:42PM +0200, Alexandre Courbot wrote:

Hello everybody,

I'm currently trying to perform very fine-grained benchmarks on a C application. Like, saving the values of a variable every time it changes, or following a chained-list of pointers when some event occurs in the program. For (good) design reasons I don't want to add special code to the program's source. In short, what I'd like to achieve is introspection of C programs without anything else than debugging symbols, and defining behaviors the monitoring program should adopt when some even occurs.

As a concrete exemple, let's say I'd like to produce a gnuplot graph with the time in abscissa and the value of a variable in ordinate. The time and values would be saved into an array every time the variable changes.

I've considered using gdb for this. I don't know much about it but it looks like it is easy to associate a gdb function to an event (i.e. "scripting" gdb instead of using it in interactive mode). Also, the great advantage of gdb is that it can catch any kind of event and let the user see directly through the C structures.

I wonder however if this is the best solution for that purpose, and if I haven't overestimated gdb scripting capabilities in that respect. Or maybe there is another tool that allows similar results (I've thought of gprof but it seems much less controllable than gdb). I'd also be interested in hearing people who attempted similar experiences (can't find anything similar after a good google search).


Neither GDB nor binutils are good tools for this.  You may want to
investigate valgrind, if it supports your platform.

Puzzled expression.


It depends on the type of performance analysis being conducted and where one is willing to make tradeoffs. valgrind, for instance, won't be able to perform more complex operations such as record linked list depth. GDB, on the other hand, will slow down the programs execution invalidating time based (but not memory based) benchmarks.

Have a look at nana (http://www.gnu.org/software/nana/) which uses GDB to do assertion checking. If the objective is to analyze the dynamic state of the program then GDB is probably a good choice. If GDB's overhead is too high, we've got a problem (too much overhead would relate back to GDB's single-step speed and that is always critical).

Andrew



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