You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When an application (or core module!) creates an event, particularly of the "error" or "critical" severity, it would be useful to have a stack trace as part of the event message.
Describe the solution you'd like
This should be an optional feature that is configurable at runtime to set a) the severity of events to record stack traces, b) the maximum stack depth to report, and c) whether to report symbol names or just addresses. It may also be useful to have this be compile-time configurable so that environments that never plan to use this feature would see no impacts.
Describe alternatives you've considered
Of course, for ground testing, gdb or other debugging features are sufficient to provide this information, assuming the tester started the core under a debugger or otherwise attached a debugger prior to the event being triggered.
Is your feature request related to a problem? Please describe.
When an application (or core module!) creates an event, particularly of the "error" or "critical" severity, it would be useful to have a stack trace as part of the event message.
Describe the solution you'd like
This should be an optional feature that is configurable at runtime to set a) the severity of events to record stack traces, b) the maximum stack depth to report, and c) whether to report symbol names or just addresses. It may also be useful to have this be compile-time configurable so that environments that never plan to use this feature would see no impacts.
At least for GCC-based environments, there's an API (https://www.gnu.org/software/libc/manual/html_node/Backtraces.html) for introspecting the call stack. I don't know if VXWorks or RTEMS or other realtime systems have this API.
Describe alternatives you've considered
Of course, for ground testing, gdb or other debugging features are sufficient to provide this information, assuming the tester started the core under a debugger or otherwise attached a debugger prior to the event being triggered.
Additional context
Requester Info
[email protected]
The text was updated successfully, but these errors were encountered: