Re: [PATCH v2 03/19] PR gdb/21226: Take DWARF stack value pieces from LSB end

[Andreas Arnez <arnez@linux.vnet.ibm.com>]

On Mon, May 15 2017, Yao Qi wrote:

> Andreas Arnez <arnez@linux.vnet.ibm.com> writes:
>
>> * DW_OP_piece shall take the piece from the LSB end as well;
>>
>
> My understanding is that this is true for a given arch or ABI.

Well, if a DWARF stack value is of some integral type, the LSB end is
well-defined, independently from the ABI.  I don't know whether any
DWARF consumer emits something like a 3-byte DW_OP_piece of an 8-byte
floating-point stack value, and what it would mean by that.  My best
guess is that it would refer to the same 3 bytes of the stack value's
in-memory representation as if the value *was* of integral type.

Or do you refer to the DWARF definition of DW_OP_piece? -- "If the piece
is located in a register, but does not occupy the entire register, the
placement of the piece within that register is defined by the ABI."
Unfortunately nothing is said about pieces from something else but
registers; thus I phrased my assumption above.  I can't verify the
assumption for all DWARF producers, but I'm pretty sure that it holds
for GCC and LLVM.

> This change will affect other big-endian architectures, like mips.

Right, the change affects (hopefully fixes) all big-endian
architectures, because stack value pieces were taken from the
lowest-addressed end so far, where they should have been taken from the
LSB end instead.  These two placement rules happen to be the same on
little-endian architectures, which are consequently unaffected by the
change.

>
>> @@ -1866,26 +1870,30 @@ read_pieced_value (struct value *v)
>>  			     p->v.mem.in_stack_memory,
>>  			     p->v.mem.addr + source_offset,
>>  			     buffer.data (), this_size);
>> +	  copy_bitwise (contents, dest_offset_bits,
>> +			intermediate_buffer, source_offset_bits % 8,
>> +			this_size_bits, bits_big_endian);
>>  	  break;
>>  
>>  	case DWARF_VALUE_STACK:
>>  	  {
>> -	    size_t n = this_size;
>> +	    struct objfile *objfile = dwarf2_per_cu_objfile (c->per_cu);
>> +	    struct gdbarch *objfile_gdbarch = get_objfile_arch (objfile);
>> +	    ULONGEST stack_value_size_bits
>> +	      = 8 * TYPE_LENGTH (value_type (p->v.value));
>>  
>> -	    if (n > c->addr_size - source_offset)
>> -	      n = (c->addr_size >= source_offset
>> -		   ? c->addr_size - source_offset
>> -		   : 0);
>> -	    if (n == 0)
>> -	      {
>> -		/* Nothing.  */
>> -	      }
>> -	    else
>> -	      {
>> -		const gdb_byte *val_bytes = value_contents_all (p->v.value);
>> +	    /* Use zeroes if piece reaches beyond stack value.  */
>> +	    if (p->size > stack_value_size_bits)
>> +	      break;
>
> Does this indicate something wrong in DWARF producer?  Does GDB need to
> emit a complaint?

I don't know any DWARF producer that would emit such a DWARF piece.
Whether it should be considered valid or not is unclear.  Probably not.
But if we emit a complaint for such a piece, then all pieces will become
unusable just because GDB can't deal with that one piece.  Before the
change, no complaint was emitted either; not sure if the author had
another reason for that.

--
Andreas