real time printf-like logging

[jacob navia]

Hi!

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

log3("points[%d]={%d,%d}\n", i, points.x, points.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!

 

[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.x, points.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

 

[Ian Collins]

Hi!

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

log3("points[%d]={%d,%d}\n", i, points.x, points.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.

 

[Yossi Kreinin]

Maybe, but it is trivial to implement.

It is indeed trivial. But I'm ashamed to admit that it took me some
time to realize it. For example, the version where you read out
strings out of the program image at the host came more natural to me
than the (simpler) version where you write them out at the target (I
didn't immediately realize that you can stuff the strings into mutable
buffers and zero the first byte to mark strings you already wrote out
to avoid repetitions, for example).

I have this impression that lots of real time logging is done by
filling structures or using other kind of pre-defined format, or by
elaborate binary serialization schemes. So the simple thing is somehow
used less than more complicated alternatives. Would you say this is
wildly wrong?

 

[Yossi Kreinin]

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.