From: Tom de Vries <tdevries@suse.de>
To: gdb-patches@sourceware.org
Subject: [gdb/testsuite] Fix error handling in gdb_file_cmd
Date: Thu, 4 Jun 2020 12:45:06 +0200 [thread overview]
Message-ID: <10439d10-c133-4738-9f39-d8295a75c2e4@suse.de> (raw)
In-Reply-To: <20200604102423.GA2054@delia>
[-- Attachment #1: Type: text/plain, Size: 127 bytes --]
> [gdb/testsuite] Fix PATH error in gdb_file_cmd
And a follow-up patch fixing another problem in gdb_file_cmd.
Thanks,
- Tom
[-- Attachment #2: 0002-gdb-testsuite-Fix-error-handling-in-gdb_file_cmd.patch --]
[-- Type: text/x-patch, Size: 3842 bytes --]
[gdb/testsuite] Fix error handling in gdb_file_cmd
Consider a gdb_load patch to call the gdb_file_cmd twice:
...
proc gdb_load { arg } {
if { $arg != "" } {
+ set res [gdb_file_cmd $arg]
+ if { $res != 0 } {
+ return $res
+ }
return [gdb_file_cmd $arg]
}
return 0
}
...
When running test-case gdb.base/index-cache.exp, we run into:
...
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache, other program \
already loaded (timeout).
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: check index-cache \
stats (GDB internal error)
ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache, other program \
already loaded (timeout).
...
The first timeout in more detail:
...
(gdb) file outputs/gdb.base/index-cache/index-cache^M
Load new symbol table from "index-cache"? (y or n) y^M
Reading symbols from index-cache...^M
src/gdb/dwarf2/read.c:2540: internal-error: \
void create_cus_from_index(dwarf2_per_bfd*, const gdb_byte*, offset_type, \
const gdb_byte*, offset_type): \
Assertion `per_bfd->all_comp_units.empty ()' failed.^M
A problem internal to GDB has been detected,^M
further debugging may prove unreliable.^M
Quit this debugging session? (y or n) ERROR: Couldn't load index-cache, \
other program already loaded (timeout).
...
Proc gdb_file_cmd has a gdb_expect handling the result of the file command,
and if the result is a "Load new symbol table from index-cache? (y or n) "
prompt, it sends a "y" and enters in a nested gdb_expect to handle the
result.
The first gdb_expect contains code to handle "A problem internal to GDB has
been detected", but the second one doesn't, which causes the timeout.
Fix this by removing the nested gdb_expect, and using exp_continue instead,
such that we have instead:
...
FAIL: gdb.base/index-cache.exp: test_cache_enabled_miss: \
(index-cache) (GDB internal error)
FAIL: gdb.base/index-cache.exp: test_cache_enabled_hit: \
(index-cache) (GDB internal error)
...
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-06-04 Tom de Vries <tdevries@suse.de>
* lib/gdb.exp (gdb_file_cmd): Replace incomplete gdb_expect by
exp_continue.
---
gdb/testsuite/lib/gdb.exp | 23 ++++++++---------------
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 71884b2b81..806bcfad6b 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -1762,6 +1762,7 @@ proc gdb_file_cmd { arg } {
send_gdb "file $arg\n"
set basename [file tail $arg]
+ set new_symbol_table 0
gdb_expect 120 {
-re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" {
verbose "\t\tLoaded $arg into $GDB; .gnu_debugdata found but no LZMA available"
@@ -1779,22 +1780,14 @@ proc gdb_file_cmd { arg } {
return 0
}
-re "Load new symbol table from \".*\".*y or n. $" {
+ if { $new_symbol_table > 0 } {
+ perror "Couldn't load $arg, interactive prompt loop detected."
+ return -1
+ }
send_gdb "y\n" answer
- gdb_expect 120 {
- -re "Reading symbols from.*$gdb_prompt $" {
- verbose "\t\tLoaded $arg with new symbol table into $GDB"
- set gdb_file_cmd_debug_info "debug"
- return 0
- }
- timeout {
- perror "Couldn't load $arg, other program already loaded (timeout)."
- return -1
- }
- eof {
- perror "Couldn't load $arg, other program already loaded (eof)."
- return -1
- }
- }
+ incr new_symbol_table
+ set arg "$arg -- with new symbol table"
+ exp_continue
}
-re "No such file or directory.*$gdb_prompt $" {
perror "($arg) No such file or directory"
next prev parent reply other threads:[~2020-06-04 10:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-04 10:24 [PATCH][gdb/testsuite] Fix PATH error " Tom de Vries
2020-06-04 10:45 ` Tom de Vries [this message]
2020-06-04 11:51 ` [gdb/testsuite] Fix error handling " Pedro Alves
2020-06-04 14:38 ` Tom de Vries
2020-06-04 11:43 ` [PATCH][gdb/testsuite] Fix PATH error " Pedro Alves
2020-06-04 11:51 ` Tom de Vries
2020-06-04 12:18 ` Pedro Alves
2020-06-04 13:05 ` Tom de Vries
2020-06-04 13:22 ` Pedro Alves
2020-06-04 14:18 ` [committed][gdb/testsuite] Fix use of fail in gdb_cmd_file Tom de Vries
2020-06-04 15:14 ` [PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd Tom de Vries
2020-06-04 15:27 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=10439d10-c133-4738-9f39-d8295a75c2e4@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox