From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 861BC3858C60; Tue, 7 Dec 2021 09:19:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 861BC3858C60 From: "mark at klomp dot org" To: libabigail@sourceware.org Subject: [Bug default/21023] The abidw tool does not appear to read dwarf from .dwp files associated with executables Date: Tue, 07 Dec 2021 09:19:13 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mark at klomp dot org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Dec 2021 09:19:13 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D21023 --- Comment #9 from Mark Wielaard --- Hi Thomas, (In reply to Thomas Schwinge from comment #8) > So I wanted to use libabigail on GCC '-gsplit-dwarf' object files > ('*.o'/'*.dwo'), and found that it doesn't work. Then found this existing > PR; confirming that status is still as per Andrew's 2018-06-16 comment: > 'eu-readelf'/elfutils (Ubuntu 0.176-1.1build1 in my case) appears to work, > but 'abidw'/libabigail (current master branch) doesn't even open the '*.d= wo' > file, per 'strace'. >=20 > If I wanted to try help implement that (but no promises how far I'll > get...), are Mark's 2018-06-05 comments here re "libabigail will need to = use > a few new interfaces" still applicable, to get started? Yes, that is still applicable. Where libabigail now uses dwarf_next_unit, it should use dwarf_get_units. dwarf_get_units provides the type of the unit, if it is a type unit or split unit, it will not only provide the CU DIE, but also the "Sub DIE", that is = the Type DIE (for type units) or Split DIE (for split units). It can then follow the Split DIE to get the actual DIE tree for that unit (the CU DIE is just = the Skeleton DIE in that case). These DIEs might come from different files (Dwarf objects) than the main Dw= arf. So where libabigail now uses Dwarf_Off as a (unique) identifier of a DIE (a= nd uses dwarf_offdie or dwarf_offdie_types to reconstruct a Dwarf_Die from a Dwarf_Off), it should now use the Dwarf_Die void *addr field as unique identifier (and use dwarf_die_addr_die to reconstruct the Dwarf_Die). See libdw.h for more documentation. Specifically: /* Gets the next Dwarf_CU (unit), version, unit type and if available the CU DIE and sub (type) DIE of the unit. Returns 0 on success, -1 on error or 1 if there are no more units. To start iterating provide NULL for CU. If version < 5 the unit type is set from the CU DIE if available (DW_UT_compile for DW_TAG_compile_unit, DW_UT_type for DW_TAG_type_unit or DW_UT_partial for DW_TAG_partial_unit), otherwise it is set to zero. If unavailable (the version or unit type is unknown) the CU DIE is cleared. Likewise if the sub DIE isn't isn't available (the unit type is not DW_UT_type or DW_UT_split_type) the sub DIE tag is cleared. */ extern int dwarf_get_units (Dwarf *dwarf, Dwarf_CU *cu, Dwarf_CU **next_cu, Dwarf_Half *version, uint8_t *unit_type, Dwarf_Die *cudie, Dwarf_Die *subdie) __nonnull_attribute__ (3); /* Given a Dwarf_Die addr returns a (reconstructed) Dwarf_Die, or NULL if the given addr didn't come from a valid Dwarf_Die. In particular it will make sure that the correct Dwarf_CU pointer is set for the Dwarf_Die, the Dwarf_Abbrev pointer will not be set up yet (it will only be once the Dwarf_Die is used to read attributes, children or siblings). This functions can be used to keep a reference to a Dwarf_Die which you want to refer to later. The addr, and the result of this function, is only valid while the associated Dwarf is valid. */ extern Dwarf_Die *dwarf_die_addr_die (Dwarf *dbg, void *addr, Dwarf_Die *result) __nonnull_attribute__ (3); One note to keep in mind. Each .dwo is also represented as a Dwarf handle, = and a Dwarf_Die from a split dwarf file will have that as Dwarf handle. But the above functions work on the main Dwarf handle (which owns the sub Dwarf han= dles and will clean them up when you drop the main Dwarf handle). Cheers, Mark --=20 You are receiving this mail because: You are on the CC list for the bug.=