diff mbox

Big-endian targets: Fix implptrpiece.exp

Message ID m38tp8n5ol.fsf@oc1027705133.ibm.com
State New, archived
Headers

Commit Message

Andreas Arnez Feb. 14, 2017, 3:38 p.m. UTC 
  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(-)

Comments

Yao Qi Feb. 14, 2017, 4:59 p.m. UTC | #1 
On Tue, Feb 14, 2017 at 3:38 PM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:
> 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?

Yes, patch is OK.

>
> [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.]

Reproduced.  Could you file a bug for it?
Andreas Arnez Feb. 14, 2017, 5:32 p.m. UTC | #2 
On Tue, Feb 14 2017, Yao Qi wrote:

> On Tue, Feb 14, 2017 at 3:38 PM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote:

[...]

>> Sure.  See updated patch below.  Is this OK then?
>
> Yes, patch is OK.

Thanks, pushed.

>> [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.]
>
> Reproduced.  Could you file a bug for it?

Sure: https://sourceware.org/bugzilla/show_bug.cgi?id=21162

--
Andreas
diff mbox

Patch

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"