[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug default/20369] Support DW_TAG_type_unit



https://sourceware.org/bugzilla/show_bug.cgi?id=20369

--- Comment #18 from Mark Wielaard <mjw at redhat dot com> ---
(In reply to dodji from comment #12)
> The main reason why I need to support the DW_TAG_type_unit specifically is
> that elfutils doesn't provide a way to get the parent node of a given DIE.
> 
> So libabigail builds that relationship itself, where each DIE is identified
> by its DIE offset. Because a DIE A coming from the .debug_info section, a
> DIE B coming from the alternate debug insection and DIE C coming from the
> .type_units section can all have the same offset even though they are
> different DIEs, libabigail maintains three different "DIE -> parent DIE"
> hash tables; one for .debug_info DIEs, one for alternate debug info DIE and
> one for the .type_units DIEs.  Well, until now, we only had two, but now
> it's going to have three.

We discussed this on IRC already a little. But for the record if you want to
build a relationship yourself then identifying a DIE with just the offset isn't
enough. You can either use the Dwarf_Die addr field as unique identifier for a
DIE (you'll need to keep a copy of the Dwarf_Die then if you want to
reconstruct it). Or you can keep a pair of Dwarf_CU* and offsets to identify a
DIE. In the last case you can use the Dwarf_CU to extract the information from
which Dwarf/file and which section info/type the Dwarf_Die came and reconstruct
it with dwarf_offdie or dwarf_offdie_types as appropriate.

I saw the current code tries to second guess where libdw got a Dwarf_Die from
by inspecting the reference form of the referring Dwarf_Die. I believe that is
the wrong way to do this. Each Dwarf_Die has a cu field that provides the
information you need without having to do any low-level DWARF form parsing
yourself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.