On Fri, 2018-02-09 at 21:58 +0100, Mark Wielaard wrote:
> The DWARF5 spec says DW_FORM_data16 is constant class (128bit value).
> But we treat it as if it is block class. So to use a attribute that is
> encoded as DW_FORM_data16 use dwarf_formblock, not dwarf_form[us]data.
>
> We cannot use dwarf_
On Fri, 2018-02-09 at 18:25 +0100, Mark Wielaard wrote:
> Handle the new DW_FORM_implicit_const. The value of this form is embedded
> in the abbrev data (as sleb128) and not in the info DIE data. This also
> adds a new function dwarf_getabbrevattr_data which allows getting any
> data/value associat
On Thu, 2018-02-08 at 17:06 +0100, Mark Wielaard wrote:
> This just makes sure we know how the new forms are encoded.
> It doesn't yet handle them in the dwarf_form* functions.
> But it does make it possible to skip them when reading DWARF5.
>
> DW_FORM_implicit_const has zero size (the value is i
On Tue, 2018-01-30 at 13:34 +0100, Mark Wielaard wrote:
> The dwarf_nextcu and dwarf_next_unit functions provide information to
> construct the offset to construct the associated CU DIE using dwarf_offdie
> or dwarf_offdie_types. This requires the user to know beforehand where
> to DIE data is sto
On Tue, 2018-01-30 at 13:33 +0100, Mark Wielaard wrote:
> Parse DWARF5 units, add the unit_type to the Dwarf_CU and generalize some
> code calculating the header length and getting at the first DIE of a unit.
> Unit headers can have different sizes depending on the unit type.
I pushed this to mast
eu-elflint uses ebl_check_reloc_target_type to determine whether a section
is a valid relocation target. In Fedora rawhide there are new ELF notes
(annobin) which have relocations against them in ET_REL files. eu-elflint
currently flags these as invalid. It looks like that is not correct.
I cannot
