Re: Log every call and exit in embedded system

[Michael Snyder <Michael.Snyder@palmsource.com>]

On Sat, 2007-03-24 at 20:05 +0000, John Zoidberg wrote:
> Hi,
> 
> I am studying a FOSS embedded OS and would like to understand its
> callgraph (especially assembly calls during OS initialization).
> Since this is an embedded OS it means I have no access to profiling or
> coverage features from GCC.

That actually depends.  Don't dismiss the possibility too lightly.

> I've also looked into GDB manual for tracing and logging, but didn't
> found anything that can solve my problem in a direct way. I tried
> backtrace but couldn't get any usefull information.

Not sure what you mean by that, but you may be misunderstanding
what "backtrace" does.  It prints the current call stack at any
given time.  You would want at least some of this info if you 
need to construct a callgraph, but it's not sufficient.

> The idea is to understand its callgraph, so it's a one time operation.
> I'm not looking for profiling or statistics (of course that being able
> to do this would be great).

Now -- there are static tools that will construct a callgraph
simply by analyzing the source code.  If this isn't what you
want, what is it that you need in addition to a static callgraph?

Some sort of frequency counts?  You say you're not looking for
statistics...

> ATM, my idea is to create a script that:
> (1) parses objdump output to get symbols and
> (2) create a GDB command file that sets a breakpoint in every symbol.
> I'll then read the commands file, run the target and manually take
> note of the function name and source code filename (because there are
> symbol name collisions) everytime a breakpoint occurs.

Not sure what you mean by "manually".  GDB will print that info 
automatically each time a breakpoint is hit.  You can just pipe
the output to a file.

You can attach a command script to each breakpoint to tell gdb
to continue, so that you don't have to do that manually either.

> Problems with this approach:
> (1) unable to tell when a function returns, so it's impossible to tell
> what is the level at which functions are being called. This is
> especially true in assembly files (i.e., was it a JMP or was it a
> RET?)

Presumably your breakpoints will be at the function entry point.
You won't get any events on RET.  You'll only get call events, 
or potentially JMP events in assembly code.

> (2) unable to track macros and inline code :(

GDB has some mechanisms for both -- look in the manual.

> (3) can GBD handle thousands of breakpoints?

No problem -- but it has to set and unset them at every stop event, 
and that requires a message cycle between host and target.  The time
it takes to start and stop will increase linearly with the number
of breakpoints.

> (4) it's a slow manual process because when a breakpoint fires I'll
> have to take note of the symbol:filename and issue a continue

See above, there is no reason why that needs to be done manually.


> 
> OFFTOPIC: how can I define string variables for GDB command files? I
> tried "set" but it doesn't accept strings. What I would like to do is
> this:
> export SOURCE_ROOT=/path/to/source/code/with/lots/of/dirs/
> dir $SOURCE_ROOT
> dir $SOURCE_ROOT/core
> dir $SOURCE_ROOT/util
> dir $SOURCE_ROOT/drivers
> dir $SOURCE_ROOT/drivers/ethernet

You may want to use some scripting system to drive this.
Shell script, makefile, expect, tcl, python...