real time printf-like logging

[Yossi Kreinin]

Hi!

There's this way of doing real time debug prints which look like
printf calls:

log3("points[%d]={%d,%d}\n", i, points[i].x, points[i].y);

The implementation writes something like {format-string-ptr, num-args,
arg0, arg1, arg2} to a binary log buffer. The buffer is written out in
binary form, and then the formatting is done at the host. The string
pointers are "decoded" by reading the constant format strings out of
the program image or, more portably, they can be collected by the
target code when the binary log buffer is written out, at the cost of
a slight time & space overhead.

Is there a free implementation of something like this? Do you think it
would be useful?

-- Yossi

[jacob navia]

Yossi Kreinin wrote:

Hi!

There's this way of doing real time debug prints which look like
printf calls:

log3("points[%d]={%d,%d}\n", i, points[i].x, points[i].y);

The implementation writes something like {format-string-ptr, num-args,
arg0, arg1, arg2} to a binary log buffer. The buffer is written out in
binary form, and then the formatting is done at the host. The string
pointers are "decoded" by reading the constant format strings out of
the program image or, more portably, they can be collected by the
target code when the binary log buffer is written out, at the cost of
a slight time & space overhead.

Is there a free implementation of something like this? Do you think it
would be useful?

-- Yossi

Of course it is possible. I did it when implementing a debugger for an
embedded DSP. The printf specs were kept in the host,
and the in place debugger sent the raw data through a serial line.

Now, "real time" will be another thing, since this takes time, the
serial line keeps the processor busy, and there is obviously a
big debugger overhead. But there is no free lunch!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Ian Collins]

Yossi Kreinin wrote:

Hi!

There's this way of doing real time debug prints which look like
printf calls:

log3("points[%d]={%d,%d}\n", i, points[i].x, points[i].y);

Certainly.

The implementation writes something like {format-string-ptr, num-args,
arg0, arg1, arg2} to a binary log buffer. The buffer is written out in
binary form, and then the formatting is done at the host. The string
pointers are "decoded" by reading the constant format strings out of
the program image or, more portably, they can be collected by the
target code when the binary log buffer is written out, at the cost of
a slight time & space overhead.

Yes, I used something like this on a couple of projects where we only
had a very small area of non-volatile storage for logging. I still have
at least one in production where this technique is used for assert logs.

Is there a free implementation of something like this? Do you think it
would be useful?

Maybe, but it is trivial to implement.

--
Ian Collins.

[Yossi Kreinin]

On Dec 1, 9:31 pm, jacob navia <[e-mail]:

>
Of course it is possible. I did it when implementing a debugger for an
embedded DSP. The printf specs were kept in the host,
and the in place debugger sent the raw data through a serial line.

Cool stuff. Was it by any chance the CCS? I think it has a trace
facility like this.

Now, "real time" will be another thing, since this takes time, the
serial line keeps the processor busy, and there is obviously a
big debugger overhead. But there is no free lunch!

Well, sometimes you could DMA them out pretty fast in "standalone"
runs (without a debugger attached), so the lunch would be cheap if not
completely free.

I think you can do it more neatly when you control the software tools
implementation. That is, you can have a compiler/linker convert format
specs to IDs and emit a table of ID->string for the debugger to use.
What I thought was the case when you don't control the tools, so you
have the strings linked into the executable (wasting a certain amount
of space), and then you parse the executable and read the strings out
of it, or you have the strings written out at the target. Which, of
course, isn't a big deal, either; I just wondered if there's a free
implementation people use for this.