kernel: Trap in `log_error()` when a debugger is attached.
authorwhitequark <whitequark@whitequark.org>
Fri, 24 Apr 2020 19:37:47 +0000 (19:37 +0000)
committerwhitequark <whitequark@whitequark.org>
Sun, 3 May 2020 12:02:34 +0000 (12:02 +0000)
commite9f2d3f009d0c9da59758a6e14cddf1cebae1f59
tree85614baea1761b9f10ea70bd84eb4a07cb2ab473
parentcf14e186eb6c89696cd1db4b36697a4e80b6884a
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>
kernel/log.cc
kernel/log.h