[Dwarf-Discuss] RFC: DW_OP_GNU_regval_type clarification

[Joel Brobecker]

Hello,

I have a question regarding the DW_OP_GNU_regval_type operation.
This is the only documentation I could find for this new
operation:

    http://www.dwarfstd.org/doc/040408.1.html

This is on powerpc, as part of a DW_AT_GNU_call_site_value attribute.
The DIE in question is:

        .uleb128 0xc     # (DIE (0x115) DW_TAG_GNU_call_site_parameter)
        .byte   0x2      # DW_AT_location
        .byte   0x90     # DW_OP_regx
        .uleb128 0x21
        .byte   0x3      # DW_AT_GNU_call_site_value
        .byte   0xf5     # DW_OP_GNU_regval_type
        .uleb128 0x3f
        .uleb128 0x25

In this case, register 0x25=63 is f31, and DIE 0x25 refers
to a 4-bytes float.

The problem arrises from the fact that the parameter value is
passed via an 8-byte register, using the corresponding 8-byte float
format, while the parameter type is indeed a 4-byte float.

My question is: Should the entire contents of the register be read
first, and then the type be used to perform a cast? Or should
only part of the register value be read, according to the type
given as argument of the DW_OP_GNU_regval_type?

At the moment, one of our compiler gurus tells me:
> I think that the compiler generates debug info tailored to its
> understanding of DW_OP_regval_type, i.e. the value of the register is
> to be interpreted in the specified type.  With this view, this should
> be equivalent to the debug info generated for the parameter itself,
> i.e. the value of the register given by DW_OP_regx interpreted in the
> type of the formal parameter.
> 
> It uses DW_OP_regval_type here because it thinks it needs to specify
> the type of the value as well as its location, whereas for
> DW_TAG_formal_parameter the type is already specified as an attribute.

At the moment, GDB takes a different view, and thus reads the register
value incorrectly. The documentation at the URL above says:

    | The DW_OP_regval_type operation takes two parameters. The first
    | parameter is an unsigned LEB128 number, which identifies a register
    | whose contents is to be pushed onto the stack. The second parameter
    | is an unsigned LEB128 number that represents the offset of a
    | debugging information entry in the current compilation unit, which
    | must be a DW_TAG_base_type entry that provides the type of the value
    | contained in the specified register.

In your opinion, should we fix the compiler, or the debugger?

Thank you,
-- 
Joel