Runtime Errors over Compile Time Errors #71282
Unanswered
TorstenRobitzki
asked this question in
Q&A
Replies: 2 comments 7 replies
-
As a general note, when using RTT as logging backend, the logs are written into a memory area. This is commonly much faster than UART, so So, having CONFIG_LOG_MODE_IMMEDIATE=y should not impact timings much. |
Beta Was this translation helpful? Give feedback.
1 reply
-
@TorstenRobitzki Sure, but how? |
Beta Was this translation helpful? Give feedback.
6 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Currently, I'm investigating, why I'm unable to log messages to the RTT backend, with having
CONFIG_LOG_MODE_DEFERRED=y
to not slow down the program flow, when no RTT console is attached. In the middle, I ended up with this call stack:And found myself trying to understand the assembler code in swap_helper.S until I understood, that the code just forwarded a problem that was reported somewhere else. Inspecting the arguments passed to
k_sys_fatal_error_handler
and looking up the address on the other side of thesignal handler called
, led me to the conclusion, that this was "simply" an assert.This was the failing function:
And here, I would like to hear your opinions. If I understand the function correctly, it will always fail given a certain compile time configuration (CONFIG_LOG_PROCESS_THREAD and asserts enabled). So, as soon as the function is linked into the binary, the linker proofed, that there is a mistake.
Wouldn't it be more helpful, to not have the function at all, if the configuration is set? This would result in compile and / or linker error and probably would save a lot of time for those, who think, they might try to call that function to get the logging working.
Beta Was this translation helpful? Give feedback.
All reactions