[PATCH] dwarf2loc.c: Perform a pointer to address conversion for DWARF_VALUE_MEMORY

[Pedro Alves]

On 11/25/2015 06:17 AM, Kevin Buettner wrote:
> This patch fixes the following failures for rl78-elf:
> 
> FAIL: gdb.base/vla-datatypes.exp: print int_vla
> FAIL: gdb.base/vla-datatypes.exp: print unsigned_int_vla
> FAIL: gdb.base/vla-datatypes.exp: print double_vla
> FAIL: gdb.base/vla-datatypes.exp: print float_vla
> FAIL: gdb.base/vla-datatypes.exp: print long_vla
> FAIL: gdb.base/vla-datatypes.exp: print unsigned_long_vla
> FAIL: gdb.base/vla-datatypes.exp: print char_vla
> FAIL: gdb.base/vla-datatypes.exp: print short_vla
> FAIL: gdb.base/vla-datatypes.exp: print unsigned_short_vla
> FAIL: gdb.base/vla-datatypes.exp: print unsigned_char_vla
> FAIL: gdb.base/vla-datatypes.exp: print foo_vla
> FAIL: gdb.base/vla-datatypes.exp: print bar_vla
> FAIL: gdb.base/vla-datatypes.exp: print vla_struct_object
> FAIL: gdb.base/vla-datatypes.exp: print vla_union_object
> FAIL: gdb.base/vla-ptr.exp: print td_vla
> FAIL: gdb.mi/mi-vla-c99.exp: evaluate complete vla
> 
> The first failure in this bunch occurs due to printing an incorrect
> result for a variable length array:
> 
>     print int_vla
>     $1 = {-1, -1, -1, -1, -1}
> 
> The result should actually be this:
> 
>     $1 = {0, 2, 4, 6, 8}
> 
> When I started examining this bug, I found that printing an
> individual array element worked correctly.  E.g. "print int_vla[2]"
> resulted in 4 being printed.  I have not looked closely to see why
> this is the case.
> 
> I found that evaluation of the location expression for int_vla was
> causing problems.  This is the relevant DWARF entry for int_vla:
> 
> <2><15a>: Abbrev Number: 10 (DW_TAG_variable)
>     <15b>   DW_AT_name        : (indirect string, offset: 0xbf): int_vla
>     <15f>   DW_AT_decl_file   : 1
>     <160>   DW_AT_decl_line   : 35
>     <161>   DW_AT_type        : <0x393>
>     <165>   DW_AT_location    : 4 byte block: 86 7a 94 2  (DW_OP_breg22 (r22): -6; DW_OP_deref_size: 2)
> 
> I found that DW_OP_breg22 was providing a correct result.
> DW_OP_deref_size was fetching the correct value from memory.  However,
> the value being fetched should be considered a pointer.
> DW_OP_deref_size zero extends the fetched value prior to pushing
> it onto the evaluation stack.  (The DWARF-4 document specifies this
> action; so GDB is faithfully implementing the DWARF-4 specification.)
> 
> However, zero extending the pointer is not sufficient for converting
> that value to an address for rl78 and (perhaps) other architectures
> which define a `pointer_to_address' method.  (I suspect that m32c
> would have the same problem.)
> 
> Ideally, we would perform the pointer to address conversion in
> DW_OP_deref_size.  We don't, however, know the type of the object
> that the address refers to in DW_OP_deref_size.  I can't think
> of a way to infer the type at that point in the code.

I'd think this would be another case of old-style untyped-dwarf, so
should be handled with dwarf_expr_address_type.  But that doesn't
distinguish data / code pointers types, only sizes, which isn't sufficient.

In that case, this seems reasonable to me.

Thanks,
Pedro Alves