* [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd @ 2020-06-04 10:24 Tom de Vries 2020-06-04 10:45 ` [gdb/testsuite] Fix error handling " Tom de Vries 2020-06-04 11:43 ` [PATCH][gdb/testsuite] Fix PATH error " Pedro Alves 0 siblings, 2 replies; 12+ messages in thread From: Tom de Vries @ 2020-06-04 10:24 UTC (permalink / raw) To: gdb-patches Hi, When building gdb using this patch: ... static void file_command (const char *arg, int from_tty) { + gdb_assert (0); /* FIXME, if we lose on reading the symbol file, we should revert the exec file, but that's rough. */ exec_file_command (arg, from_tty); ... and running the testsuite, we run into: ... Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ... PASS: gdb.ada/O2_float_param.exp: compilation foo.adb FAIL: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \ (GDB internal error) PATH: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \ (GDB internal error) ... Fix this by using the basename in the FAIL message, such that we have: ... Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ... PASS: gdb.ada/O2_float_param.exp: compilation foo.adb FAIL: gdb.ada/O2_float_param.exp: (foo) (GDB internal error) ... Tested on x86_64-linux. Any comments? Thanks, - Tom [gdb/testsuite] Fix PATH error in gdb_file_cmd gdb/testsuite/ChangeLog: 2020-06-04 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_file_cmd): Only use basename of loaded file in fail message. --- gdb/testsuite/lib/gdb.exp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 444cea01c3..71884b2b81 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -1761,6 +1761,7 @@ proc gdb_file_cmd { arg } { } send_gdb "file $arg\n" + set basename [file tail $arg] 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" @@ -1800,7 +1801,7 @@ proc gdb_file_cmd { arg } { return -1 } -re "A problem internal to GDB has been detected" { - fail "($arg) (GDB internal error)" + fail "($basename) (GDB internal error)" gdb_internal_error_resync return -1 } ^ permalink raw reply [flat|nested] 12+ messages in thread
* [gdb/testsuite] Fix error handling in gdb_file_cmd 2020-06-04 10:24 [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd Tom de Vries @ 2020-06-04 10:45 ` Tom de Vries 2020-06-04 11:51 ` Pedro Alves 2020-06-04 11:43 ` [PATCH][gdb/testsuite] Fix PATH error " Pedro Alves 1 sibling, 1 reply; 12+ messages in thread From: Tom de Vries @ 2020-06-04 10:45 UTC (permalink / raw) To: gdb-patches [-- 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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gdb/testsuite] Fix error handling in gdb_file_cmd 2020-06-04 10:45 ` [gdb/testsuite] Fix error handling " Tom de Vries @ 2020-06-04 11:51 ` Pedro Alves 2020-06-04 14:38 ` Tom de Vries 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-04 11:51 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 6/4/20 11:45 AM, Tom de Vries wrote: >> [gdb/testsuite] Fix PATH error in gdb_file_cmd > > And a follow-up patch fixing another problem in gdb_file_cmd. LGTM. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [gdb/testsuite] Fix error handling in gdb_file_cmd 2020-06-04 11:51 ` Pedro Alves @ 2020-06-04 14:38 ` Tom de Vries 0 siblings, 0 replies; 12+ messages in thread From: Tom de Vries @ 2020-06-04 14:38 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 359 bytes --] On 04-06-2020 13:51, Pedro Alves wrote: > On 6/4/20 11:45 AM, Tom de Vries wrote: >>> [gdb/testsuite] Fix PATH error in gdb_file_cmd >> >> And a follow-up patch fixing another problem in gdb_file_cmd. > > LGTM. Updated log message to accommodate for commit 0cfcd4f003 "[gdb/testsuite] Fix use of fail in gdb_cmd_file", committed as attached. Thanks, - Tom [-- Attachment #2: 0001-gdb-testsuite-Fix-error-handling-in-gdb_file_cmd.patch --] [-- Type: text/x-patch, Size: 3867 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: ... ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache -- with new \ symbol table into gdb (GDB internal error). ERROR: Couldn't load outputs/gdb.base/index-cache/index-cache -- with new \ symbol table into gdb (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 63a9e3da53..3cdaefaa9c 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -1761,6 +1761,7 @@ proc gdb_file_cmd { arg } { } send_gdb "file $arg\n" + 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" @@ -1778,22 +1779,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" ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd 2020-06-04 10:24 [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd Tom de Vries 2020-06-04 10:45 ` [gdb/testsuite] Fix error handling " Tom de Vries @ 2020-06-04 11:43 ` Pedro Alves 2020-06-04 11:51 ` Tom de Vries 1 sibling, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-04 11:43 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 6/4/20 11:24 AM, Tom de Vries wrote: > @@ -1800,7 +1801,7 @@ proc gdb_file_cmd { arg } { > return -1 > } > -re "A problem internal to GDB has been detected" { > - fail "($arg) (GDB internal error)" > + fail "($basename) (GDB internal error)" > gdb_internal_error_resync > return -1 > } The -re above has the exact same issue in the ERROR call. I have no idea why this one is a fail while everywhere else in the procedure perror is used. Seems inconsistent. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd 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 0 siblings, 1 reply; 12+ messages in thread From: Tom de Vries @ 2020-06-04 11:51 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 04-06-2020 13:43, Pedro Alves wrote: > On 6/4/20 11:24 AM, Tom de Vries wrote: >> @@ -1800,7 +1801,7 @@ proc gdb_file_cmd { arg } { >> return -1 >> } >> -re "A problem internal to GDB has been detected" { >> - fail "($arg) (GDB internal error)" >> + fail "($basename) (GDB internal error)" >> gdb_internal_error_resync >> return -1 >> } > > The -re above has the exact same issue in the ERROR call. Right, but the PATH detection is only for testnames, not for error messages. > I have no idea why this one is a fail while everywhere else > in the procedure perror is used. Seems inconsistent. It is locally inconsistent indeed, but it is consistent with all other handling of "A problem internal to GDB has been detected" in gdb.exp. Thanks, - Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd 2020-06-04 11:51 ` Tom de Vries @ 2020-06-04 12:18 ` Pedro Alves 2020-06-04 13:05 ` Tom de Vries 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-04 12:18 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 6/4/20 12:51 PM, Tom de Vries wrote: > On 04-06-2020 13:43, Pedro Alves wrote: >> On 6/4/20 11:24 AM, Tom de Vries wrote: >>> @@ -1800,7 +1801,7 @@ proc gdb_file_cmd { arg } { >>> return -1 >>> } >>> -re "A problem internal to GDB has been detected" { >>> - fail "($arg) (GDB internal error)" >>> + fail "($basename) (GDB internal error)" >>> gdb_internal_error_resync >>> return -1 >>> } >> >> The -re above has the exact same issue in the ERROR call. > > Right, but the PATH detection is only for testnames, not for error messages. That seems like a bug in the PATH detection stuff to me: Running /home/pedro/brno/pedro/gdb/binutils-gdb-2/build/../src/gdb/testsuite/gdb.ada/O2_float_param.exp ... ERROR: (/home/pedro/brno/pedro/gdb/binutils-gdb-2/build/gdb/testsuite/outputs/gdb.ada/O2_float_param/foo) (GDB internal error) This makes is as hard to diff gdb.sum files as a FAIL/PASS with a build path. > >> I have no idea why this one is a fail while everywhere else >> in the procedure perror is used. Seems inconsistent. > > It is locally inconsistent indeed, but it is consistent with all other > handling of "A problem internal to GDB has been detected" in gdb.exp. If you look at those other spots, they are using fail/pass in the other surrounding -re's, and thus that's just another fail among all those. I.e., those cases are internally consistent. Like e.g.: -re "${sentinel}" { fail "${test} (pattern ${index} + sentinel)" set ok 0 } -re ".*A problem internal to GDB has been detected" { fail "${test} (GDB internal error)" set ok 0 gdb_internal_error_resync } timeout { fail "${test} (pattern ${index} + sentinel) (timeout)" set ok 0 } The gdb_file_cmd one started out with a message string that didn't even include the parens around the "GDB internal error" string in 04e7407c59a: + -re "A problem internal to GDB has been detected" { + fail "($arg) GDB internal error" + gdb_internal_error_resync + return -1 + } The parens were later added in 5b7d00507b9: -re "A problem internal to GDB has been detected" { - fail "($arg) GDB internal error" + fail "($arg) (GDB internal error)" Arguably that patch should have switched to perror instead. A FAIL message with only text wrapped in parens is odd, since the trailing "(foo)" text is not supposed to count as test message. So in effect, you could say that this fail has no test message, the same as if you wrote: fail "" Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd 2020-06-04 12:18 ` Pedro Alves @ 2020-06-04 13:05 ` Tom de Vries 2020-06-04 13:22 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Tom de Vries @ 2020-06-04 13:05 UTC (permalink / raw) To: Pedro Alves, gdb-patches On 04-06-2020 14:18, Pedro Alves wrote: > On 6/4/20 12:51 PM, Tom de Vries wrote: >> On 04-06-2020 13:43, Pedro Alves wrote: >>> On 6/4/20 11:24 AM, Tom de Vries wrote: >>> I have no idea why this one is a fail while everywhere else >>> in the procedure perror is used. Seems inconsistent. >> >> It is locally inconsistent indeed, but it is consistent with all other >> handling of "A problem internal to GDB has been detected" in gdb.exp. > > If you look at those other spots, they are using fail/pass in the other > surrounding -re's, and thus that's just another fail among all those. > I.e., those cases are internally consistent. Like e.g.: > > -re "${sentinel}" { > fail "${test} (pattern ${index} + sentinel)" > set ok 0 > } > -re ".*A problem internal to GDB has been detected" { > fail "${test} (GDB internal error)" > set ok 0 > gdb_internal_error_resync > } > timeout { > fail "${test} (pattern ${index} + sentinel) (timeout)" > set ok 0 > } > > The gdb_file_cmd one started out with a message string that didn't > even include the parens around the "GDB internal error" string in 04e7407c59a: > > + -re "A problem internal to GDB has been detected" { > + fail "($arg) GDB internal error" > + gdb_internal_error_resync > + return -1 > + } > > The parens were later added in 5b7d00507b9: > > -re "A problem internal to GDB has been detected" { > - fail "($arg) GDB internal error" > + fail "($arg) (GDB internal error)" > > Arguably that patch should have switched to perror instead. > A FAIL message with only text wrapped in parens is odd, > since the trailing "(foo)" text is not supposed to count as > test message. So in effect, you could say that this fail has > no test message, the same as if you wrote: > > fail "" OK, I see your point, I'll prepare a patch for this, so let's settle on the error message. How about: ... - fail "($arg) (GDB internal error)" + perror "Couldn't load $arg into $GDB (GDB internal error)." ... ? Thanks, - Tom ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd 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 0 siblings, 1 reply; 12+ messages in thread From: Pedro Alves @ 2020-06-04 13:22 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 6/4/20 2:05 PM, Tom de Vries wrote: > OK, I see your point, I'll prepare a patch for this, so let's settle on > the error message. How about: > ... > - fail "($arg) (GDB internal error)" > + perror "Couldn't load $arg into $GDB (GDB internal error)." > ... > ? LGTM, since it's what the other -re's use. (That leaves the open question of whether we want to include the full paths in the ERROR, but that can be seen as an orthogonal issue if you'd like.) Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
* [committed][gdb/testsuite] Fix use of fail in gdb_cmd_file 2020-06-04 13:22 ` Pedro Alves @ 2020-06-04 14:18 ` Tom de Vries 2020-06-04 15:14 ` [PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd Tom de Vries 0 siblings, 1 reply; 12+ messages in thread From: Tom de Vries @ 2020-06-04 14:18 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 679 bytes --] [ was: Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd ] On 04-06-2020 15:22, Pedro Alves wrote: > On 6/4/20 2:05 PM, Tom de Vries wrote: > >> OK, I see your point, I'll prepare a patch for this, so let's settle on >> the error message. How about: >> ... >> - fail "($arg) (GDB internal error)" >> + perror "Couldn't load $arg into $GDB (GDB internal error)." >> ... >> ? > > LGTM, since it's what the other -re's use. > OK, committed as attached. > (That leaves the open question of whether we want to include the > full paths in the ERROR, but that can be seen as an orthogonal issue > if you'd like.) Yes, I'd prefer that. Thanks, - Tom [-- Attachment #2: 0001-gdb-testsuite-Fix-use-of-fail-in-gdb_cmd_file.patch --] [-- Type: text/x-patch, Size: 2018 bytes --] [gdb/testsuite] Fix use of fail in gdb_cmd_file When building gdb using this patch: ... static void file_command (const char *arg, int from_tty) { + gdb_assert (0); ... and running the testsuite, we run into: ... Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ... PASS: gdb.ada/O2_float_param.exp: compilation foo.adb FAIL: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \ (GDB internal error) PATH: gdb.ada/O2_float_param.exp: (outputs/gdb.ada/O2_float_param/foo) \ (GDB internal error) FAIL: gdb.ada/O2_float_param.exp: frame ... The FAIL detecting the GDB internal error is generated by this clause in gdb_file_cmd: ... -re "A problem internal to GDB has been detected" { fail "($arg) (GDB internal error)" gdb_internal_error_resync return -1 } ... The fail message has no text outside parenthesis, and could be considered empty. Also, it's the only clause in the gdb_expect that uses fail, the rest uses perror. Fix this by replacing the fail by perror, such that we have: ... Running src/gdb/testsuite/gdb.ada/O2_float_param.exp ... PASS: gdb.ada/O2_float_param.exp: compilation foo.adb ERROR: Couldn't load outputs/gdb.ada/O2_float_param/foo into \ gdb (GDB internal error). UNRESOLVED: gdb.ada/O2_float_param.exp: frame ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-06-04 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_file_cmd): Use perror instead of fail. --- gdb/testsuite/lib/gdb.exp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 444cea01c3..63a9e3da53 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -1800,7 +1800,7 @@ proc gdb_file_cmd { arg } { return -1 } -re "A problem internal to GDB has been detected" { - fail "($arg) (GDB internal error)" + perror "Couldn't load $arg into $GDB (GDB internal error)." gdb_internal_error_resync return -1 } ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd 2020-06-04 14:18 ` [committed][gdb/testsuite] Fix use of fail in gdb_cmd_file Tom de Vries @ 2020-06-04 15:14 ` Tom de Vries 2020-06-04 15:27 ` Pedro Alves 0 siblings, 1 reply; 12+ messages in thread From: Tom de Vries @ 2020-06-04 15:14 UTC (permalink / raw) To: Pedro Alves, gdb-patches [-- Attachment #1: Type: text/plain, Size: 490 bytes --] [ was: Re: [committed][gdb/testsuite] Fix use of fail in gdb_cmd_file ] On 04-06-2020 16:18, Tom de Vries wrote: > [ was: Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd ] > > On 04-06-2020 15:22, Pedro Alves wrote: >> On 6/4/20 2:05 PM, Tom de Vries wrote: >> (That leaves the open question of whether we want to include the >> full paths in the ERROR, but that can be seen as an orthogonal issue >> if you'd like.) > > Yes, I'd prefer that. > How about this? Thanks, - Tom [-- Attachment #2: 0001-gdb-testsuite-Remove-path-names-from-error-messages-in-gdb_file_cmd.patch --] [-- Type: text/x-patch, Size: 2845 bytes --] [gdb/testsuite] Remove path names from error messages in gdb_file_cmd In gdb_file_cmd, perror is called with error message strings using $arg and $GDB, both of which contain path names, which makes comparison of gdb.sum files more difficult. Fix this by using: - [file tail $arg] instead of $arg - GDB instead of $GDB. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-06-04 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (gdb_file_cmd): Avoid path names in error messages. --- gdb/testsuite/lib/gdb.exp | 18 +++++++++++------- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 3cdaefaa9c..9a0620a2bf 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 new_symbol_table 0 + set basename [file tail $arg] 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" @@ -1780,36 +1781,39 @@ proc gdb_file_cmd { arg } { } -re "Load new symbol table from \".*\".*y or n. $" { if { $new_symbol_table > 0 } { - perror "Couldn't load $arg, interactive prompt loop detected." + perror [join [list "Couldn't load $basename," + "interactive prompt loop detected."]] return -1 } send_gdb "y\n" answer incr new_symbol_table - set arg "$arg -- with new symbol table" + set suffix "-- with new symbol table" + set arg "$arg $suffix" + set basename "$basename $suffix" exp_continue } -re "No such file or directory.*$gdb_prompt $" { - perror "($arg) No such file or directory" + perror "($basename) No such file or directory" return -1 } -re "A problem internal to GDB has been detected" { - perror "Couldn't load $arg into $GDB (GDB internal error)." + perror "Couldn't load $basename into GDB (GDB internal error)." gdb_internal_error_resync return -1 } -re "$gdb_prompt $" { - perror "Couldn't load $arg into $GDB." + perror "Couldn't load $basename into GDB." return -1 } timeout { - perror "Couldn't load $arg into $GDB (timeout)." + perror "Couldn't load $basename into GDB (timeout)." return -1 } eof { # This is an attempt to detect a core dump, but seems not to # work. Perhaps we need to match .* followed by eof, in which # gdb_expect does not seem to have a way to do that. - perror "Couldn't load $arg into $GDB (eof)." + perror "Couldn't load $basename into GDB (eof)." return -1 } } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd 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 0 siblings, 0 replies; 12+ messages in thread From: Pedro Alves @ 2020-06-04 15:27 UTC (permalink / raw) To: Tom de Vries, gdb-patches On 6/4/20 4:14 PM, Tom de Vries wrote: > [gdb/testsuite] Remove path names from error messages in gdb_file_cmd > > In gdb_file_cmd, perror is called with error message strings using $arg and > $GDB, both of which contain path names, which makes comparison of gdb.sum > files more difficult. > > Fix this by using: > - [file tail $arg] instead of $arg > - GDB instead of $GDB. > > Tested on x86_64-linux. > > gdb/testsuite/ChangeLog: > > 2020-06-04 Tom de Vries <tdevries@suse.de> > > * lib/gdb.exp (gdb_file_cmd): Avoid path names in error messages. LGTM. Thanks, Pedro Alves ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-04 15:27 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-04 10:24 [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd Tom de Vries 2020-06-04 10:45 ` [gdb/testsuite] Fix error handling " Tom de Vries 2020-06-04 11:51 ` 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).