[ECOS] Valgrind - A Heads Up.
Mon Jan 5 20:21:00 GMT 2004
Just a heads up on developments over at the Valgrind end of the
You may be aware of Valgrind, an excellent debugging tool for
(Disclaimer: I have nothing to do with eCos, or Valgrind accept as a
user of both.)
Be patient, you will soon see the application to eCos and then go
"Oooh! That is very very interesting!"
Here I quote the docs....
Valgrind is a flexible tool for debugging and profiling Linux-x86
executables. The tool consists of a core, which provides a
synthetic x86 CPU in software, and a series of "skins", each of
which is a debugging or profiling tool. The architecture is
modular, so that new skins can be created easily and without
disturbing the existing structure.
The memcheck skin detects memory-management problems in your
programs. All reads and writes of memory are checked, and calls to
malloc/new/free/delete are intercepted. As a result, memcheck can
detect the following problems:
* Use of uninitialised memory
* Reading/writing memory after it has been free'd
* Reading/writing off the end of malloc'd blocks
* Reading/writing inappropriate areas on the stack
* Memory leaks -- where pointers to malloc'd blocks are lost forever
* Mismatched use of malloc/new/new  vs free/delete/delete 
* Overlapping src and dst pointers in memcpy() and related functions
* Some misuses of the POSIX pthreads API
cachegrind is a cache profiler. It performs detailed simulation of
the I1, D1 and L2 caches in your CPU and so can accurately pinpoint
the sources of cache misses in your code. If you desire, it will
show the number of cache misses, memory references and instructions
accruing to each line of source code, with per-function, per-module
and whole-program summaries. If you ask really nicely it will even
show counts for each individual x86 instruction.
helgrind is a new debugging skin, designed to find data races in
multithreaded programs. What helgrind looks for is memory locations
which are accessed by more than one (POSIX p-)thread, but for which
no consistently used (pthread_mutex_)lock can be found. Such
locations are indicative of missing synchronisation between
threads, and could cause hard-to-find timing-dependent problems.
Now the latest improvement (currently only in the latest version in
CVS not in any released version) is Full Virtualization. This means
that it doesn't even need to get in via the dynamically link library
back door. It can run on eCos Linux synthetic target statically linked
At this stage you should be saying, "Oooh, that is very
interesting". This means no matter what weird thing your target CPU
is, you can test your code under Valgrind by compiling it for the
However, I believe additional work needs to be done to get eCos to
gain the full benefit from Valgrind.
* Valgrind needs to understand eCos memory pools.
* Valgrind needs to understand eCos threading scheduler.
So this is just a little pointer to anyone that may find this useful.
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : firstname.lastname@example.org
A Million Monkeys can inflict worse things than just Shakespeare on
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss