debugability: pipeline and component ids in trace messages #530
Conversation
|
@lgirdwood I'm aware of conflicts. Please review current progress on this subject, to ensure that we're on the right track before I go full on with changing all trace macros in our project. |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
Going in the right direction. Think we can make this a little more generic for other users too.
akloniex
force-pushed
the
ids-in-trace
branch
from
945b66f to
0994968
Compare
|
@lgirdwood Currently build fails on Travis while building host target, due to cast from pointer to uint32_t. As host is built with x64 architecture, this warning seems legit, but I don't know how to work around this. |
|
@akloniex you could use uintptr_t instead of uint32_t as the host versions of the trace macros just call printf directly anyway (i.e. we dont use logger on host). |
akloniex
force-pushed
the
ids-in-trace
branch
7 times, most recently
from
c75b5c3 to
0e0fc34
Compare
2 arbitrary IDs may now be passed to specialized versions of trace_event macro: trace_event_with_ids. Also optimized runtime stack usage of _trace_event functions. Signed-off-by: ArturX Kloniecki <arturx.kloniecki@linux.intel.com>
Implemented set of macros for pipelines to allow reporting of pipeline and component IDs. Refactor all traces to provide useful, human readible messages. Signed-off-by: ArturX Kloniecki <arturx.kloniecki@linux.intel.com>
Signed-off-by: ArturX Kloniecki <arturx.kloniecki@linux.intel.com>
Signed-off-by: ArturX Kloniecki <arturx.kloniecki@linux.intel.com>
akloniex
force-pushed
the
ids-in-trace
branch
from
0e0fc34 to
4217992
Compare
|
@lgirdwood @akloniex Yay, all the checks are green now! |
3 participants
In reference to #508