Re: Log every call and exit in embedded system

["John Zoidberg" <the.real.doctor.zoidberg@gmail.com>]

On 3/26/07, Michael Snyder <Michael.Snyder@palmsource.com> wrote:
> 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.

What I mean is that due to the nesting level of calls I'm unable to
get a useful call stack. I can see the call stack at a certain level,
but I can't see what happened in deeper levels (and a lot happens
there).

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

I suspect those tools won't support assembly modules and will have
problems with branching (i.e. I'll have to debug to know where
execution flows). But if those tools are capable of handling hundreds
of files across multiple directories they will still be useful. Since
I've not tested any, which ones would you recommend?

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

Using "set logging"

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

Using "commands"

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

I've re-checked GDB's behavior for assembly and it (1) breaks on the
first instruction of an assembly symbol (on the jmp scenario) and (2)
I can know if it was a call by checking the backtrace.

> > (2) unable to track macros and inline code :(
>
> GDB has some mechanisms for both -- look in the manual.

I've checked the manual, made a simple test and confirmed what I
suspected: I'm unable to set breakpoints in macros/inline.

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

Thanks for your help!