Re: C programs introspection using binutils/gdb

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Apr 02, 2004 at 10:17:46AM -0500, Andrew Cagney wrote:
> 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.

On the contrary, valgrind _can_ do things like record linked list
depth.  You have to write a skin for it.  Most people think of the
memcheck skin when they talk about valgrind, but it is an arbitrary
instrumentation engine.

> 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).

> >>>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.

This means that nana isn't a good option for him, if I understand its
manual right?  It looks to be source annotation based.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer