[PATCH] gdb/testsuite: fix failure in gdb.python/py-send-packet.exp

[PATCH] gdb/testsuite: fix failure in gdb.python/py-send-packet.exp

[Andrew Burgess]

While working on another patch I noticed that, when run on an AArch64
target, the test gdb.python/py-send-packet.exp was failing:

  Traceback (most recent call last):
    File "<string>", line 1, in <module>
    File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
  line 106, in run_auxv_send_packet_test
      assert string == expected_result
  AssertionError
  Error while executing Python code.
  (gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function

The test uses 'maint packet ...' to send a packet to gdbserver, and
then captures the output in TCL.  This output is then passed through
to a Python function, which performs some actions using the Python
API, and compares the results from the Python API to the results
captured in TCL from 'maint packet ...'.

The problem is that the output captured in TCL contains lots of things
like '\x000', when this is passed through to Python the '\x' causes
this to be treated as an escape code, which isn't what we want - we
want the actual string "\x000".

So, in the TCL part of the test we were expanding '\x' to '\\x', this
seemed to work fine for my testing on x86-64.

However, on AArch64 what I see is that the results from 'maint packet
...' contain a literal '\' character followed by a literal 'x'
character.  When GDB prints this in the 'maint packet' output, GDB
escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.

However, now our TCL test script kicks in and tries to "fix" the '\x',
this means we now have '\\\x', which isn't correct.

The problem is that in the TCL script we are too restrictive, we
expand '\x' to '\\x', but really, we should be expanding all '\'
characters, regardless of what follows them.  This is what this patch
does.

After this the gdb.python/py-send-packet.exp test passes on AArch64
for me.
---
 gdb/testsuite/gdb.python/py-send-packet.exp | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.python/py-send-packet.exp b/gdb/testsuite/gdb.python/py-send-packet.exp
index 11f0043db9b..5cb2f5a656c 100644
--- a/gdb/testsuite/gdb.python/py-send-packet.exp
+++ b/gdb/testsuite/gdb.python/py-send-packet.exp
@@ -80,9 +80,9 @@ if { ! $skip_auxv_test } {
 	}
     }
 
-    # Expand the '\x' in the output, so we can pass a string through
-    # to Python.
-    set reply_data [string map {\x \\x} $reply_data]
+    # Escape any backslash characters in the output, so we can safely
+    # pass a string through to Python.
+    set reply_data [string map {\\ \\\\} $reply_data]
     gdb_assert { ![string equal "$reply_data" ""] }
 
     # Run the test, fetches the auxv data in Python and confirm it
-- 
2.25.4

Re: [PATCH] gdb/testsuite: fix failure in gdb.python/py-send-packet.exp

[Andrew Burgess]

Andrew Burgess <aburgess@redhat.com> writes:

> While working on another patch I noticed that, when run on an AArch64
> target, the test gdb.python/py-send-packet.exp was failing:
>
>   Traceback (most recent call last):
>     File "<string>", line 1, in <module>
>     File "/tmp/build/gdb/testsuite/outputs/gdb.python/py-send-packet/py-send-packet.py",
>   line 106, in run_auxv_send_packet_test
>       assert string == expected_result
>   AssertionError
>   Error while executing Python code.
>   (gdb) FAIL: gdb.python/py-send-packet.exp: call python run_auxv_send_packet_test function
>
> The test uses 'maint packet ...' to send a packet to gdbserver, and
> then captures the output in TCL.  This output is then passed through
> to a Python function, which performs some actions using the Python
> API, and compares the results from the Python API to the results
> captured in TCL from 'maint packet ...'.
>
> The problem is that the output captured in TCL contains lots of things
> like '\x000', when this is passed through to Python the '\x' causes
> this to be treated as an escape code, which isn't what we want - we
> want the actual string "\x000".
>
> So, in the TCL part of the test we were expanding '\x' to '\\x', this
> seemed to work fine for my testing on x86-64.
>
> However, on AArch64 what I see is that the results from 'maint packet
> ...' contain a literal '\' character followed by a literal 'x'
> character.  When GDB prints this in the 'maint packet' output, GDB
> escapes the '\' for us, thus we get '\\x' printed by 'maint packet'.
>
> However, now our TCL test script kicks in and tries to "fix" the '\x',
> this means we now have '\\\x', which isn't correct.
>
> The problem is that in the TCL script we are too restrictive, we
> expand '\x' to '\\x', but really, we should be expanding all '\'
> characters, regardless of what follows them.  This is what this patch
> does.
>
> After this the gdb.python/py-send-packet.exp test passes on AArch64
> for me.

I've gone ahead and merged this patch.

Thanks,
Andrew


> ---
>  gdb/testsuite/gdb.python/py-send-packet.exp | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.python/py-send-packet.exp b/gdb/testsuite/gdb.python/py-send-packet.exp
> index 11f0043db9b..5cb2f5a656c 100644
> --- a/gdb/testsuite/gdb.python/py-send-packet.exp
> +++ b/gdb/testsuite/gdb.python/py-send-packet.exp
> @@ -80,9 +80,9 @@ if { ! $skip_auxv_test } {
>  	}
>      }
>  
> -    # Expand the '\x' in the output, so we can pass a string through
> -    # to Python.
> -    set reply_data [string map {\x \\x} $reply_data]
> +    # Escape any backslash characters in the output, so we can safely
> +    # pass a string through to Python.
> +    set reply_data [string map {\\ \\\\} $reply_data]
>      gdb_assert { ![string equal "$reply_data" ""] }
>  
>      # Run the test, fetches the auxv data in Python and confirm it
> -- 
> 2.25.4