This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Big-endian targets: Fix implptrpiece.exp
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- Cc: "gdb-patches at sourceware dot org" <gdb-patches at sourceware dot org>
- Date: Tue, 14 Feb 2017 12:59:13 +0000
- Subject: Re: [PATCH] Big-endian targets: Fix implptrpiece.exp
- Authentication-results: sourceware.org; auth=none
- References: <m3wpdrus83.fsf@oc1027705133.ibm.com>
Hi Andreas,
Sorry for the delayed review. I read this patch at least twice in the last
month, but didn't review because I can't understand it fully, and was
interrupted to do something else.
On Thu, Jan 19, 2017 at 12:52 PM, Andreas Arnez
<arnez@linux.vnet.ibm.com> wrote:
> The test case implptrpiece.exp accesses the second byte of the short
> integer number 1 and expects it to be zero. This is valid for
> little-endian targets, but fails on big-endian targets.
>
> This is fixed by determining the expected value in an
> endianness-independent way.
This is quite clever, but I don't like it, :) because every time I read it,
it takes me a while what is the test trying to do.
>
> gdb/testsuite/ChangeLog:
>
> * gdb.dwarf2/implptrpiece.exp: Fix check for big-endian targets.
> ---
> gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> index af7dd37..3f6e0d6 100644
> --- a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> +++ b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> @@ -119,4 +119,7 @@ if ![runto_main] {
> return -1
> }
>
> -gdb_test "print/d p\[-1\]" " = 0"
> +# Access the second byte of s through an implicit pointer to the third
> +# byte of s, using a negative offset. Compare that to the second byte of
> +# the short integer 1 in target byte order.
> +gdb_test "p/d p\[-1\] - ((signed char *)(short\[1\]){1})\[1\]" " = 0"
> --
Can we check the result of p[-1] explicitly for different endianness?
We can fill in the first two bytes of s with 0x5678, for example, and
it is expected to see different results of p[-1] for different endianness.
--
Yao (齐尧)