Re: [PATCH] Big-endian targets: Fix implptrpiece.exp

[Yao Qi <qiyaoltc at gmail dot com>]

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?

-- 
Yao (齐尧)