Re: [PATCH] Big-endian targets: don't ignore offset into DW_OP_implicit_value

[Andreas Arnez <arnez at linux dot vnet dot ibm dot com>]

On Wed, Jan 25 2017, Yao Qi wrote:

> On 17-01-12 20:24:27, Andreas Arnez wrote:
>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-op-stack-value.exp b/gdb/testsuite/gdb.dwarf2/dw2-op-stack-value.exp
>> index c28dcca..808f983 100644
>> --- a/gdb/testsuite/gdb.dwarf2/dw2-op-stack-value.exp
>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-op-stack-value.exp
>> @@ -45,7 +45,7 @@ gdb_test_multiple $test $test {
>>      -re ":\[ \t\]*0xaa551234\r\n$gdb_prompt $" {
>>  	# big endian
>>  	pass $test
>> -	gdb_test "p/x implicit4to2" " = 0x3344"
>> +	gdb_test "p/x implicit4to2" " = 0x1122"
>>  	gdb_test "p/x implicit4to4" " = 0x11223344"
>
> It takes me a while to understand this.  I am wondering is it a valid
> test case? how does compiler generate a DIE for a 2-byte variable
> from a 4-byte implicit value.

AFAIK never.  I don't know why a compiler should emit a larger immediate
value than necessary.  So this is an artificial test.

> DWARF spec isn't clear on this case to me.

Right, DWARF does not specify this.  Even so, we may want GDB to exhibit
defined behavior for such corner cases as well.  I probably wouldn't
have added such a test, but I didn't want remove it either, because it
could be considered useful in the sense that it tests GDB's
"implementation-defined" behavior for this case.

> It has nothing to do with your patch, but I just raise this
> question when I read your patch.
>
>> +# Byte-aligned objects with simple location descriptions.
>> +switch $endian { big {set val 0x345678} little {set val 0x785634} }
>> +gdb_test "print/x def_implicit_s" " = \\{a = 0x12, b = $val\\}"
>> +gdb_test "print/x def_implicit_s.b" " = $val"
>> +gdb_test "print/x def_implicit_a" \
>> +    " = \\{0x1, 0x12, 0x23, 0x34, 0x45, 0x56, 0x67, 0x78, 0x89\\}"
>
> All these values are from debug information rather than inferior memory,
> does it make sense to run these tests above with both big and little
> endianess?

I've tried, but I don't know to make it work.  Switching to the opposite
endianness affects more than just the byte order of variable contents;
the variables are not even found any more.  Any idea?

> Otherwise, patch is good to me.

Thanks!

--
Andreas