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: Andreas Arnez <arnez at linux dot vnet dot ibm dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: "gdb-patches\@sourceware.org" <gdb-patches at sourceware dot org>
- Date: Tue, 14 Feb 2017 16:38:34 +0100
- Subject: Re: [PATCH] Big-endian targets: Fix implptrpiece.exp
- Authentication-results: sourceware.org; auth=none
- References: <m3wpdrus83.fsf@oc1027705133.ibm.com> <CAH=s-PON2KZnCBgC6XeuJxegqsdbLs8b=CeCbdmPzvO=kbs-0w@mail.gmail.com>
On Tue, Feb 14 2017, Yao Qi wrote:
>> 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.
Hehe, I see...
>> -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.
Sure. See updated patch below. Is this OK then?
[Side note: While developing the patch I also found that a slightly
different typecast expression -- with the dimension removed from the
array typecast -- causes a GDB internal error:
(gdb) p ((char*)(short[]){1})[1]
/home/arnez/src/binutils-gdb/gdb/gdbtypes.c:4722: internal-error:
type* copy_type(const type*): Assertion `TYPE_OBJFILE_OWNED (type)'
failed.
I see this bug on s390x and amd64, but haven't spent much time
investigating it yet.]
--
Andreas
-- >8 --
Subject: [PATCH v2] Big-endian targets: Fix implptrpiece.exp
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 distinguishing the expected value by endianness.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/implptrpiece.exp: Fix check for big-endian targets.
---
gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
index af7dd37..ef483c0 100644
--- a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
+++ b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp
@@ -80,7 +80,7 @@ Dwarf::assemble $asm_file {
{name s}
{type :$struct_label}
{location {
- const1u 1
+ const2u 0x5678
stack_value
piece 2
const1u 2
@@ -119,4 +119,17 @@ if ![runto_main] {
return -1
}
-gdb_test "print/d p\[-1\]" " = 0"
+# Determine endianness.
+set endian "little"
+gdb_test_multiple "show endian" "determine endianness" {
+ -re ".* (big|little) endian.*$gdb_prompt $" {
+ set endian $expect_out(1,string)
+ pass "endianness: $endian"
+ }
+}
+
+# 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 0x5678 in target byte order.
+switch $endian { little {set val 0x56} big {set val 0x78} }
+gdb_test "p/x p\[-1\]" " = $val"
--
2.5.0