[Dwarf-Discuss] DW_FORM_data1 and DW_AT_const_value

[Michael Eager]

Tom Tromey wrote:
> I got the following DWARF from gcc svn:
> 
>  <2><8e2>: Abbrev Number: 5 (DW_TAG_variable)
>     <8e3>   DW_AT_name        : (indirect string, offset: 0x167): funclocal_ro	
>     <8e7>   DW_AT_decl_file   : 1	
>     <8e8>   DW_AT_decl_line   : 15	
>     <8e9>   DW_AT_type        : <0x901>	
>     <8ed>   DW_AT_const_value : 203	
> [...]
>  <1><8fa>: Abbrev Number: 8 (DW_TAG_base_type)
>     <8fb>   DW_AT_byte_size   : 4	
>     <8fc>   DW_AT_encoding    : 5	(signed)
>     <8fd>   DW_AT_name        : int	
>  <1><901>: Abbrev Number: 9 (DW_TAG_const_type)
>     <902>   DW_AT_type        : <0x8fa>	
> 
> 
> This dump doesn't say so, but the DW_AT_const_value is represented as
> <DW_FORM_data1 203>.
> 
> This inspired some local discussion, and we thought it couldn't hurt to
> ask a wider audience.  The question is whether a reader should
> sign-extend that "203".
> 
> GDB currently does sign extension here, because the type of the variable
> is signed.  However, at least Roland and Jakub are of the opinion that
> DW_FORM_data1 should not be sign extended in this situation, I believe
> on the basis that DW_FORM_data* should just supply bits.
> 
> The DWARF spec is reasonably unclear:
> 
>     The data in DW_FORM_data1, DW_FORM_data2, DW_FORM_data4 and
>     DW_FORM_data8 can be anything. Depending on context, it may be a signed
>     integer, an unsigned integer, a floating-point constant, or anything
>     else. A consumer must use context to know how to interpret the bits,
>     which if they are target machine data (such as an integer or floating
>     point constant) will be in target machine byte-order.
> 
>     If one of the DW_FORM_data<n> forms is used to represent a signed or
>     unsigned integer, it can be hard for a consumer to discover the context
>     necessary to determine which interpretation is intended. Producers are
>     therefore strongly encouraged to use DW_FORM_sdata or DW_FORM_udata for
>     signed and unsigned integers respectively, rather than DW_FORM_data<n>.
> 
> Nothing here really indicates what contextual information should be
> considered.

DW_FORM_data<n> is really just a sequence of bits, without any interpretation.
The meaning of the bits and the context is whatever the producer and consumer
agree is relevant where the DW_FORM_data<n> attribute is used.

> The DW_AT_const_value docs may support the no-extension interpretation,
> based on the use of the word "value":
> 
>     The value is the actual constant value of the variable, represented as
>     it would be on the target architecture.

One problem is that the value is not "the actual constant value of the variable,
represented as it would be on the target architecture" meaning the exact same
bit pattern which represents the value on the target.  The DWARF standard
anticipates that there would be no manipulation of the DW_AT_const_value bit
pattern.

The "correct" approach would be to use DW_FORM_data4 and supply four bytes of
data for the value of the four-byte variable.  Instead gcc is generating some 
"equivalent" shorter value.

DW_FORM_data<n> assumes that the producer and consumer share an interpretation
of what the value represents, based on the context.  As soon as you diverge
from the "actual value" for DW_AT_const_value, you are into the area where
both producer and consumer need to agree on the meaning.

In this case, the context would appear to be that the variable has a type
which is a signed integer, which suggests to me that the value should be sign
extended.  If you used DW_AT_const_value with an unsigned type, I'd suggest
zero extending a DW_FORM_data<n> which was not the same size as the variable.
If the variable were something else (like float) I'd throw up my hands in
confusion.  But that's just my view -- gcc/gdb are free to have completely
different interpretations of what the bits in DW_FORM_data mean.

> It appears that GCC has worked this way for quite a while, so my
> inclination is to change GDB to match.  However, at the very least it
> would be good to see a clarification in the spec.

I'm not sure what that clarification would be.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077