Simple event recorder with GDB support

[ghost]

Does a simple event recorder have a interest in MODM. Is has very low impact on performance and code size compared to traditional logging. It's only a simple circular buffer of type std::uintptr_t and everything is defined in a single header file. The power full magic lies in a Python GDB script which implements a evr-print command, it parses the header file and translates the binary data to a human readable output directly from GDB.
Every event is simply defined in enums and a struct. They can have from 0 to 7 arguments and they are automatically cast'ed in a variadic template. All event id's consists of id, group, type and argument count combined together in a uintptr_t. All trace calls can be turn off and optimized away without changing the code.
It has really helped me in my project and gives a great overview of a running program, but i will not blindly implement it in MODM, GDB with different embedded python versions sucks and I fear it will give some troubles. If it has interest it could start as a standalone project and evolve from there. I got the idea from CMSIS RTOS2 they have implemented a similar solution i C for their IDE.

// examples on log calls..
 evr::trace<evr_mutex_thread_wait>(this, current);

 evr::trace<evr_thread_create>(options, func, arg);

Example on output:

(gdb) evr-print 
0x413820 <evr::detail::ev_buffer::buf+32>
buffer_size: 129

id                             group         type   args...
----------------------------------------------------------------------
thread_sleep_for               thread        api    004132c0 00001388 
thread_flags_wait              thread        api    00413380 00000003 00000001 00000000 
thread_create                  thread        api    004110f0 004037c5 00412240 
thread_delete                  thread        api    00413380 
thread_is_terminated           thread        api    00413380 
thread_exit                    thread        op     00413380 
thread_terminate               thread        api    00413380 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_join                    thread        api    00413380 
thread_is_terminated           thread        api    00413380 
thread_flags_set               thread        api    00413380 00000003 
thread_waiting_delay_completed thread        op     004132c0 
thread_sleep_for               thread        api    004132c0 00001388 
thread_flags_wait              thread        api    00413380 00000003 00000001 00000000 
thread_create                  thread        api    004110f0 004037c5 00412240 
thread_delete                  thread        api    00413380 
thread_is_terminated           thread        api    00413380 
thread_exit                    thread        op     00413380 
thread_terminate               thread        api    00413380 
thread_waiting_delay_completed thread        op     00413380 
thread_sleep_for               thread        api    00413380 00000064 
thread_waiting_delay_completed thread        op     00413380 

[salkinium]

Yes, this could be interesting, however, I would make the transport layer configurable, so that you can also send out events over RTT, UART, CAN.

There is a similiar, but more generic way: Offline formatting like defmt, where each format string gets a unique ID and the arguments are passed as binary, but can be formatted properly on the receiver.
See also pw_tokenizer for a C++ implementation.

I would prefer the offline formatter, since that's more generic and can also be used for event tracking.