Re: Log every call and exit in embedded system

[Mathieu Lacage <Mathieu dot Lacage at sophia dot inria dot fr>]

On Tue, 2007-03-27 at 12:07 +0100, John Zoidberg wrote:

> Your tool seems very interesting, it's unfortunate it's not ready for
> embedded systems.
> On the documentation you mention malloc, but some embedded systems
> don't have the code for malloc. Moreover, no embedded system uses
> glibc, it uses newlib, uclib, and others... this means that the code
> that is linked may not have the support for it (i.e. there are missing
> functions).
> There is the issue of the target code (the part that is linked to the
> application) must be compiled with the corresponding GCC (for the
> target system).
> And besides all this, there is the issue of where to log the
> information or how to send it.

The way I have implemented this is that I store in a circular buffer
(one per user thread) the address of the function. Then, I have another
thread (the manager thread) which reads data from every circular buffer
and writes it in a global log file. It also stores in this global log
file the memory map of your program whenever it changes because of a
dlopen. The thread stuff is really an optimization to avoid as much as
possible locking from the user program if I can avoid it: you could
write into the log file directly from the __cyg_* functions.

And then, there is a post-processing tool which reads the binary log and
generates a human-readable output based on the program memory map, the
symbol addresses and the debugging information found in the binaries.

There is some platform-specific code to make sure that I am notified
upon every memory map change (I place an int3 breakpoint in the r_debug
data structure to get link map changes through a unix signal). You could
avoid this problem by simply scanning the link map all the time whenever
you write a new symbol in the log file.


Mathieu
--