This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

incorrect signed data


I was just investigating some signed-value inconsistencies I found
between libdwarf and libdw, while working on a little experiment[1].  I
think elfutils is actually handling dwarf_formsdata incorrectly.

Libdwarf doesn't have dwarf_decl_line et al., so I was coding that bit
manually, but I got some negative values from dwarf_formsdata.  An
example raw attr is data1 0xb5, which gave me -75.

DWARF4 section 7.5.4 states that values of data1/2/4/8 may be signed or
unsigned integers, or anything else depending on context.  So when
libdwarf's dwarf_formsdata treats 0xb5 as signed for -75, I think that's
the proper interpretation of context.  On the other hand, libdw's
dwarf_formsdata does "*return_sval = *attr->valp", which in C's
promotion rules will not sign-extend! (from unsigned char to int64_t)
So libdw's dwarf_formsdata reads 0xb5 as 179.  The rest of data2/4/8 are
using read_2/4/8ubyte_unaligned, which is also wrong IMO.

DWARF4 section 2.14 states that DW_AT_decl_file/line/column are all
unsigned constants, but dwarf_decl_line/column (and _file internally)
are treating these as signed values, using dwarf_formsdata.  I think
they're just lucky that this isn't getting sign-extended, but really
these functions should be using dwarf_formudata.

- dwarf_formsdata ought to sign-extend small data.
- dwarf_decl_file/line/column should use dwarf_formudata.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]