[RFC PATCH 2/2] fix py-value-cc.exp test for big endian target

[RFC PATCH 2/2] fix py-value-cc.exp test for big endian target

[Victor Kamensky]

On any big endian target py-value-cc.exp fails like this:

FAIL: gdb.python/py-value-cc.exp: u's second field via field

python print(u[u_fields[1]])
0 '\000'
(gdb) FAIL: gdb.python/py-value-cc.exp: u's second field via field

The reason is that test case is not endian agnostic.
Test program variable 'u' has type of 'union U { int a;
char c; };'. Test program writes 99 into u.a and expects to see
it in field 'u.c'. But it would only work on little endian
system where 'c' field of U union conicide with least
significant byte of 'a' field.

Proposed fix stores "symetric" value into 'a' field of 'u',
so most siginificant byte and least siginifican byte of
are the same, so 'c' field would have the same value
regardless whether test runs on big endian or little endian
system.

gdb/testsuite/ChangeLog:

2014-10-24  Victor Kamensky  <victor.kamensky@linaro.org>
	* gdb.python/py-value-cc.cc (func): Store in u.a value
	with same most and least significant bytes.
	* gdb.python/py-value-cc.exp: Fix test for big endian
	target.
---
 gdb/testsuite/gdb.python/py-value-cc.cc  | 2 +-
 gdb/testsuite/gdb.python/py-value-cc.exp | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.python/py-value-cc.cc b/gdb/testsuite/gdb.python/py-value-cc.cc
index 7ea4f5d..d6d4d35 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.cc
+++ b/gdb/testsuite/gdb.python/py-value-cc.cc
@@ -77,7 +77,7 @@ func (const A &a)
   Btd &b_td = b1;
 
   U u;
-  u.a = 99;
+  u.a = 0x55000055; /* c is the same for big and little endian */
 
   X x;
   x.x = 101;
diff --git a/gdb/testsuite/gdb.python/py-value-cc.exp b/gdb/testsuite/gdb.python/py-value-cc.exp
index 949f04f..56003c3 100644
--- a/gdb/testsuite/gdb.python/py-value-cc.exp
+++ b/gdb/testsuite/gdb.python/py-value-cc.exp
@@ -85,8 +85,8 @@ gdb_test "python print(b_td\[b_fields\[0\]\].type.target())" "A" \
 gdb_test "python print(b_td\[b_fields\[0\]\]\['a'\])" "100" \
   "b_td.A::a via field"
 
-gdb_test "python print(u\[u_fields\[0\]\])" "99.*" "u's first field via field"
-gdb_test "python print(u\[u_fields\[1\]\])" "99.*" "u's second field via field"
+gdb_test "python print(u\[u_fields\[0\]\])" "1426063445.*" "u's first field via field"
+gdb_test "python print(u\[u_fields\[1\]\])" "85.*" "u's second field via field"
 
 gdb_test "python print len(x_fields)" "2" "number for fields in u"
 gdb_test "python print x\[x_fields\[0\]\]\['x'\]" "101" "x.x via field"
-- 
1.8.1.4

[RFC PATCH 1/2] fix implptrpiece.exp test for big endian target

[Victor Kamensky]

Currently on any big endian target implptrpiece.exp test fails
like this:

FAIL: gdb.dwarf2/implptrpiece.exp: print/d p[-1]

(gdb) print/d p[-1]
$1 = 1
(gdb) FAIL: gdb.dwarf2/implptrpiece.exp: print/d p[-1]

Test expects that value of p[-1] should be 0.

This test creates special DWARF construct with DW_OP_GNU_implicit_pointer:

 <1><25c>: Abbrev Number: 10 (DW_TAG_variable)
    <25d>   DW_AT_name        : s
    <25f>   DW_AT_type        : <0x21d>
    <263>   DW_AT_location    : 15 byte block: 8 1 9f 93 2 8 2 9f 93 1 8 3 9f 93 1      (DW_OP_const1u: 1; DW_OP_stack_value; DW_OP_piece: 2; DW_OP_const1u: 2; DW_OP_stack_value
; DW_OP_piece: 1; DW_OP_const1u: 3; DW_OP_stack_value; DW_OP_piece: 1)
 <1><273>: Abbrev Number: 11 (DW_TAG_variable)
    <274>   DW_AT_name        : p
    <276>   DW_AT_type        : <0x256>
    <27a>   DW_AT_location    : 6 byte block: f2 0 0 2 5c 2     (DW_OP_GNU_implicit_pointer: <0x25c> 2)

In description of 's' variable note byte constant value of 1, that
will be used as first piece of size 2 bytes, followed by 1 byte
piece with 2, and 1 byte piece with 3. Variable 'p' is implicit
pointer with offset 2 within 's', i.e it points right in the middle
of s. Test looks at p[-1] and expects to get most significant
byte of short type of value 1, which is 0. But in big
endian case such index points to least significant byte which
is 1. So test fails.

Fix the test by checking endianity of the target and selecting
proper index to get most significant byte of first piece.

gdb/testsuite/ChangeLog:

2014-10-24  Victor Kamensky  <victor.kamensky@linaro.org>
	* gdb.dwarf2/implptrpiece.exp: Fix handling of big
	endian target.
---
 gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
index 60a3d9f..5dcc6ea 100644
--- a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
+++ b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
@@ -119,4 +119,15 @@ if ![runto_main] {
     return -1
 }
 
-gdb_test "print/d p\[-1\]" " = 0"
+gdb_test_multiple "show endian" "getting target endian" {
+    -re ".*little endian.*$gdb_prompt $" {
+	set check_index "-1"
+	# pass silently
+    }
+    -re ".*big endian.*$gdb_prompt $" {
+	set check_index "-2"
+	# pass silently
+    }
+}
+
+gdb_test "print/d p\[$check_index\]" " = 0"
-- 
1.8.1.4

[RFC PATCH 0/2] couple big endian fixes in testsuites

[Victor Kamensky]

Hi Folks,

While I was working on arm V7 and V8 big endian issues. I noticed
couple gdb test cases that had endianity issues in test themselves.
There were failures in implptrpiece.exp and py-value-cc.exp. I
verified that ppc 64bit big endian failed those test as well.

My attempt to address endian issues in those test follows this
cover letter.

Thanks,
Victor

Victor Kamensky (2):
  fix implptrpiece.exp test for big endian target
  fix py-value-cc.exp test for big endian target

 gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 13 ++++++++++++-
 gdb/testsuite/gdb.python/py-value-cc.cc   |  2 +-
 gdb/testsuite/gdb.python/py-value-cc.exp  |  4 ++--
 3 files changed, 15 insertions(+), 4 deletions(-)

-- 
1.8.1.4

Re: [RFC PATCH 2/2] fix py-value-cc.exp test for big endian target

[Yao Qi]

Victor Kamensky <victor.kamensky@linaro.org> writes:

> The reason is that test case is not endian agnostic.
> Test program variable 'u' has type of 'union U { int a;
> char c; };'. Test program writes 99 into u.a and expects to see
> it in field 'u.c'. But it would only work on little endian
> system where 'c' field of U union conicide with least
> significant byte of 'a' field.

Yes, that make senses to me, and we've seen this fail on powerpc too.

> diff --git a/gdb/testsuite/gdb.python/py-value-cc.cc b/gdb/testsuite/gdb.python/py-value-cc.cc
> index 7ea4f5d..d6d4d35 100644
> --- a/gdb/testsuite/gdb.python/py-value-cc.cc
> +++ b/gdb/testsuite/gdb.python/py-value-cc.cc
> @@ -77,7 +77,7 @@ func (const A &a)
>    Btd &b_td = b1;
>  
>    U u;
> -  u.a = 99;
> +  u.a = 0x55000055; /* c is the same for big and little endian */

I'd like c is shown differently on big endian and little endian, and
check c's value in different endianness.  It can be something like,

 u.a = 0x55000056 or u.a = 0x55565758

>  
>    X x;
>    x.x = 101;
> diff --git a/gdb/testsuite/gdb.python/py-value-cc.exp b/gdb/testsuite/gdb.python/py-value-cc.exp
> index 949f04f..56003c3 100644
> --- a/gdb/testsuite/gdb.python/py-value-cc.exp
> +++ b/gdb/testsuite/gdb.python/py-value-cc.exp
> @@ -85,8 +85,8 @@ gdb_test "python print(b_td\[b_fields\[0\]\].type.target())" "A" \
>  gdb_test "python print(b_td\[b_fields\[0\]\]\['a'\])" "100" \
>    "b_td.A::a via field"
>  
> -gdb_test "python print(u\[u_fields\[0\]\])" "99.*" "u's first field via field"
> -gdb_test "python print(u\[u_fields\[1\]\])" "99.*" "u's second field via field"
> +gdb_test "python print(u\[u_fields\[0\]\])" "1426063445.*" "u's first field via field"

The ".*" in the pattern can be removed.

> +gdb_test "python print(u\[u_fields\[1\]\])" "85.*" "u's second field via field"

This pattern can be stricter by adding space between 85 and ".*".

-- 
Yao (齐尧)

Re: [RFC PATCH 1/2] fix implptrpiece.exp test for big endian target

[Yao Qi]

Victor Kamensky <victor.kamensky@linaro.org> writes:

>  <1><25c>: Abbrev Number: 10 (DW_TAG_variable)
>     <25d>   DW_AT_name        : s
>     <25f>   DW_AT_type        : <0x21d>
>     <263>   DW_AT_location    : 15 byte block: 8 1 9f 93 2 8 2 9f 93 1 8 3 9f 93 1      (DW_OP_const1u: 1; DW_OP_stack_value; DW_OP_piece: 2; DW_OP_const1u: 2; DW_OP_stack_value
> ; DW_OP_piece: 1; DW_OP_const1u: 3; DW_OP_stack_value; DW_OP_piece: 1)
>  <1><273>: Abbrev Number: 11 (DW_TAG_variable)
>     <274>   DW_AT_name        : p
>     <276>   DW_AT_type        : <0x256>
>     <27a>   DW_AT_location    : 6 byte block: f2 0 0 2 5c 2     (DW_OP_GNU_implicit_pointer: <0x25c> 2)
>
> In description of 's' variable note byte constant value of 1, that
> will be used as first piece of size 2 bytes, followed by 1 byte
> piece with 2, and 1 byte piece with 3. Variable 'p' is implicit
> pointer with offset 2 within 's', i.e it points right in the middle
> of s. Test looks at p[-1] and expects to get most significant
> byte of short type of value 1, which is 0. But in big
> endian case such index points to least significant byte which
> is 1. So test fails.

That sounds right to me.

> gdb/testsuite/ChangeLog:
>
> 2014-10-24  Victor Kamensky  <victor.kamensky@linaro.org>

An empty line is needed here.

> 	* gdb.dwarf2/implptrpiece.exp: Fix handling of big
> 	endian target.
> ---
>  gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> index 60a3d9f..5dcc6ea 100644
> --- a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> +++ b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
> @@ -119,4 +119,15 @@ if ![runto_main] {
>      return -1
>  }
>  
> -gdb_test "print/d p\[-1\]" " = 0"
> +gdb_test_multiple "show endian" "getting target endian" {
> +    -re ".*little endian.*$gdb_prompt $" {
> +	set check_index "-1"
> +	# pass silently
> +    }
> +    -re ".*big endian.*$gdb_prompt $" {
> +	set check_index "-2"
> +	# pass silently
> +    }
> +}
> +
> +gdb_test "print/d p\[$check_index\]" " = 0"

I'd like to check both p[-1] and [-2] on two endianness, like,

 gdb_test_multiple "show endian" "getting target endian" {
    -re ".*little endian.*$gdb_prompt $" {
        gdb_test "print/d p\[-1\]" " = 0"
        gdb_test "print/d p\[-2\]" " = 1"
	# pass silently
    }
    -re ".*big endian.*$gdb_prompt $" {
        gdb_test "print/d p\[-1\]" " = 1"
        gdb_test "print/d p\[-2\]" " = 0"
        # pass silently
    }
 }

-- 
Yao (齐尧)

Re: [RFC PATCH 2/2] fix py-value-cc.exp test for big endian target

[Pedro Alves]

On 10/29/2014 06:36 AM, Yao Qi wrote:
> Victor Kamensky <victor.kamensky@linaro.org> writes:
> 
>> The reason is that test case is not endian agnostic.
>> Test program variable 'u' has type of 'union U { int a;
>> char c; };'. Test program writes 99 into u.a and expects to see
>> it in field 'u.c'. But it would only work on little endian
>> system where 'c' field of U union conicide with least
>> significant byte of 'a' field.

...

>>    U u;
>> -  u.a = 99;
>> +  u.a = 0x55000055; /* c is the same for big and little endian */
> 
> I'd like c is shown differently on big endian and little endian, and
> check c's value in different endianness.  It can be something like,
> 
>  u.a = 0x55000056 or u.a = 0x55565758

I noticed that the proposed changes assume all supported architectures
have sizeof (int) == 4, but that's not valid assumption.  E.g.,:

(gdb) set architecture m68hc11
The target architecture is assumed to be m68hc11
(gdb) p sizeof (int)
$1 = 2

(gdb) set architecture h8300
The target architecture is assumed to be h8300
(gdb) p sizeof (int)
$2 = 2

(gdb) set architecture m32c
The target architecture is assumed to be m32c
(gdb) p sizeof (int)
$3 = 2

(gdb) set architecture avr
The target architecture is assumed to be avr
(gdb) p sizeof (int)
$4 = 2

etc.

Maybe the simplest is to make the unions use uint32_t instead
of int.

Thanks,
Pedro Alves