On 09/16/2012 03:36 PM, Tommy Hoffner wrote:
Seems like the mailer doesn't approve of Lotus Notes email
The standard way of encoding a constant value seems to be something like:
<2>< 196> DW_TAG_constant
DW_AT_name rans2
DW_AT_const_value 16
DW_AT_decl_file 1
DW_AT_decl_line 0
DW_AT_type <143>
Where we have the following abbrevation
< 6>< 69><code: 6> DW_TAG_constant DW_CHILDREN_no
< 72> DW_AT_name DW_FORM_string
< 74> DW_AT_const_value DW_FORM_data4
< 76> DW_AT_decl_file DW_FORM_data1
< 78> DW_AT_decl_line DW_FORM_data1
< 80> DW_AT_type DW_FORM_ref4
There seems to be a common agreement that we need to know the type (i.e. what
DW_AT_type points to)
to be able to interpret the data in DW_AT_const_value since DW_FORM_data4 only
gives us the size of
the data. Or as the standard says:
"constant
...
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."
But DW_FORM_data only goes up to 8 byte data.
Maybe DWARF needs a DW_FORM_data16.
In fortran I can write:
program dbq001
implicit none
real*16 rans2
parameter ( rans2 = 0.1234567890123456789012345678901_16 )
end
Giving me a 16 byte conhstant. My attempt on encoding this was
< 6>< 69><code: 6> DW_TAG_constant DW_CHILDREN_no
< 72> DW_AT_name DW_FORM_string
< 74> DW_AT_const_value DW_FORM_block1
< 76> DW_AT_decl_file DW_FORM_data1
< 78> DW_AT_decl_line DW_FORM_data1
< 80> DW_AT_type DW_FORM_ref4
The problem is that the standard section above doesn't mention DW_FORM_block1
as something that can
contain a constant. It does however say:
"In all forms, the length is the number of information bytes that follow. The
information bytes may
contain any mixture of relocated (or relocatable) addresses, references to
other debugging
information entries or data bytes."
However since all the data types above can be expressed as expressions, I seen
tools assuming that
DW_FORM_block always contains an expression.
So I think the DW_FORM_block1 above should contain the raw floating point data
(apart from the size
field). While a number of tools expect an expression evaluating to the raw bit
pattern (?) for the
16 byte data we want.
Have I missed anything.
Any hints comments on how to encode it. I realize this is actually in between
syntax and semantics.
I mean the DW_FORM is giving the syntactic part, and a some point we need to
interpret a bit pattern
as a floating point value and I guess this is in-between in the sense that it
concern how to
extract/generate the bit pattern that can be interpreted as a constant
I got the suggestion to use DW_FORM_sdata or DW_FORM_udata, since that will
make the part I'm having
trouble with unambigious, but it feel strange, since it isn't even obvious
which encoding it the
"right one" since signed and unsigned doesn't really make sense for a 16 byte
float
/Tommy Hoffner
Tommy Hoffner
Compiler Backend Development
IBM Toronto Laboratory, 8200 Warden Ave, Markham, Ontario, Canada, L6G 1C7
Tel: 905-413-2036 Tie: 313-2036 Internet: [email protected]
_______________________________________________
Dwarf-Discuss mailing list
[email protected]
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
--
Michael Eager [email protected]
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
[email protected]
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
