diff options
author | Tom de Vries <tdevries@suse.de> | 2021-09-07 01:26:26 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2021-09-07 01:26:26 +0200 |
commit | 5e1186b5b30583244d1e3dd304059348de64ed9e (patch) | |
tree | 43aa96575792949aad5e98f273183a7e391fb940 /bfd/elf32-gen.c | |
parent | d327d1b34fcf9a2f78f8d5efe1c7700f68b51962 (diff) | |
download | gdb-5e1186b5b30583244d1e3dd304059348de64ed9e.zip gdb-5e1186b5b30583244d1e3dd304059348de64ed9e.tar.gz gdb-5e1186b5b30583244d1e3dd304059348de64ed9e.tar.bz2 |
[gdb/testsuite] Handle internal-error in gdb_run_cmd
When reverting commit 5a20fadc841 the test-case
gdb.dwarf2/locexpr-data-member-location.exp fails like this:
...
FAIL: gdb.dwarf2/locexpr-data-member-location.exp: running to bar in runto \
(GDB internal error)
ERROR: Could not resync from internal error (eof)
...
and takes 1 minute to run.
The long running time is caused by running into a timeout in gdb_run_cmd, at
this point:
...
(gdb) run ^M
The program being debugged has been started already.^M
Start it from the beginning? (y or n) y^M
/home/vries/gdb_versions/devel/src/gdb/gdbtypes.c:5583: internal-error: \
Unexpected type field location kind: 4^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n)
...
Fix this by detecting the internal-error in gdb_run_cmd. We don't handle it
in gdb_run_cmd, but stash the gdb output back into the buffer using
-notransfer, and let the caller proc runto deal with it.
After the fix, the test-case just takes 2 seconds.
Tested on x86_64-linux.
Diffstat (limited to 'bfd/elf32-gen.c')
0 files changed, 0 insertions, 0 deletions