[PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Tom de Vries]

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
 	}

[gdb/testsuite] Fix error handling in gdb_file_cmd

[Tom de Vries]

[-- 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"

Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Pedro Alves]

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

Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Tom de Vries]

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

Re: [gdb/testsuite] Fix error handling in gdb_file_cmd

[Pedro Alves]

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

Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Pedro Alves]

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

Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Tom de Vries]

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

Re: [PATCH][gdb/testsuite] Fix PATH error in gdb_file_cmd

[Pedro Alves]

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

[committed][gdb/testsuite] Fix use of fail in gdb_cmd_file

[Tom de Vries]

[-- 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
 	}

Re: [gdb/testsuite] Fix error handling in gdb_file_cmd

[Tom de Vries]

[-- 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"

[PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd

[Tom de Vries]

[-- 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
         }
     }

Re: [PATCH][gdb/testsuite] Remove path names from error messages in gdb_file_cmd

[Pedro Alves]

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