diff options
author | whitequark <whitequark@whitequark.org> | 2020-04-24 19:37:47 +0000 |
---|---|---|
committer | whitequark <whitequark@whitequark.org> | 2020-05-03 12:02:34 +0000 |
commit | e9f2d3f009d0c9da59758a6e14cddf1cebae1f59 (patch) | |
tree | 85614baea1761b9f10ea70bd84eb4a07cb2ab473 /manual/CHAPTER_Appnotes.tex | |
parent | cf14e186eb6c89696cd1db4b36697a4e80b6884a (diff) | |
download | yosys-e9f2d3f009d0c9da59758a6e14cddf1cebae1f59.tar.gz yosys-e9f2d3f009d0c9da59758a6e14cddf1cebae1f59.tar.bz2 yosys-e9f2d3f009d0c9da59758a6e14cddf1cebae1f59.zip |
kernel: Trap in `log_error()` when a debugger is attached.
The workflow of debugging fatal pass errors in Yosys is flawed in
three ways:
1. Running Yosys under a debugger is sufficient for the debugger
to catch some fatal errors (segfaults, aborts, STL exceptions)
but not others (`log_error()`, `log_cmd_error()`). This is
neither obvious nor easy to remember.
2. To catch Yosys-specific fatal errors, it is necessary to set
a breakpoint at `logv_error_with_prefix()`, or at least,
`logv_error()`. This is neither obvious nor easy to remember,
and GDB's autocomplete takes many seconds to suggest function
names due to the large amount of symbols in Yosys.
3. If a breakpoint is not set and Yosys encounters with such
a fatal error, the process terminates. When debugging a crash
that takes a long time to reproduce (or a nondeterministic crash)
this can waste a significant amount of time.
To solve this problem, add a macro `YS_DEBUGTRAP` that acts as a hard
breakpoint (if available), and a macro `YS_DEBUGTRAP_IF_DEBUGGING`
that acts as a hard breakpoint only if debugger is present.
Then, use `YS_DEBUGTRAP_IF_DEBUGGING` in `logv_error_with_prefix()`
to obviate the need for a breakpoint on nearly every platform.
Co-Authored-By: Alberto Gonzalez <boqwxp@airmail.cc>
Diffstat (limited to 'manual/CHAPTER_Appnotes.tex')
0 files changed, 0 insertions, 0 deletions