Currently, if GDBserver hits some internal assertion, it exits with
error status, instead of aborting. This makes it harder to debug
GDBserver, as you can't just debug a core file if GDBserver fails an
assertion. I've had to hack the code to make GDBserver abort to debug
something several times before.
I believe the reason it exits instead of aborting, is to prevent
potentially littering the filesystem of smaller embedded targets with
core files. I think I recall Daniel Jacobowitz once saying that many
years ago, but I can't be sure. Anyhow, that seems reasonable to me.
Since we nowadays have a distinction between development and release
modes, I propose to make GDBserver abort on internal error if in
development mode, while keeping the status quo when in release mode.
Thus, after this patch, in development mode, you get:
$ ../gdbserver/gdbserver
../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
captured_main: Assertion `0' failed.
Aborted (core dumped)
$
while in release mode, you'll continue to get:
$ ../gdbserver/gdbserver
../../src/gdbserver/server.cc:3711: A problem internal to GDBserver has been detected.
captured_main: Assertion `0' failed.
$ echo $?
1
I do not think that this requires a separate configure switch.
A "--target_board=native-extended-gdbserver" run on Ubuntu 20.04 ends
up with:
=== gdb Summary ===
# of unexpected core files 29
...
for me, of which 8 are GDBserver core dumps, 7 more than without this
patch.
Change-Id: I6861e08ad71f65a0332c91ec95ca001d130b0e9d
This is a helper library that is used by gdb and gdbserver.
To send patches, follow the gdb patch submission instructions in
../gdb/CONTRIBUTE. For maintainers, see ../gdb/MAINTAINERS.
171fba11ab