diff options
author | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-07-21 18:23:19 +0100 |
---|---|---|
committer | Andrew Burgess <andrew.burgess@embecosm.com> | 2021-08-11 12:35:15 +0100 |
commit | 0e6e4b599a1572823c71e2e95a24cf17d048f42b (patch) | |
tree | 4440aa092ad2b38dbf70c818814bb8fcda47a302 /opcodes | |
parent | d03277b79793adec2508d51f8d789cd3761d9b9d (diff) | |
download | gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.zip gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.tar.gz gdb-0e6e4b599a1572823c71e2e95a24cf17d048f42b.tar.bz2 |
gdb: don't print backtrace when dumping core after an internal error
Currently, when GDB hits an internal error, and the user selects to
dump core, the recently added feature to write a backtrace to the
console will kick in, and print a backtrace as well as dumping the
core.
This was certainly not my intention when adding the backtrace on fatal
signal functionality, this feature was intended to produce a backtrace
when GDB crashes due to some fatal signal, internal errors should have
continued to behave as they did before, unchanged.
In this commit I set the signal disposition of SIGABRT back to SIG_DFL
just prior to the call to abort() that GDB uses to trigger the core
dump, this prevents GDB reaching the code that writes the backtrace to
the console.
I've also added a test that checks we don't see a backtrace on the
console after an internal error.
Diffstat (limited to 'opcodes')
0 files changed, 0 insertions, 0 deletions