| Message ID | 1414379778-5478-3-git-send-email-victor.kamensky@linaro.org |
|---|---|
| State | New |
| Headers | show |
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 ".*".
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
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"
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(-)