From: "mark at klomp dot org" <sourceware-bugzilla@sourceware.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: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <bug-21023-9487-5YhhuzY6BX@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-21023-9487@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=21023
--- Comment #6 from Mark Wielaard <mark at klomp dot org> ---
elfutils 0.171 was recently released with support for DWARF5 and split-dwarf
(including GNU DebugFission as extension to older DWARF).
https://sourceware.org/ml/elfutils-devel/2018-q2/msg00141.html
For now .dwo files are supported, but not yet .dwp files.
(Also the binutils dwp tools doesn't work with DWARF5 split dwarf.)
It will take a bit more programming to also add .dwp support, but hopefully the
structure of the elfutils code is now so that this isn't major surgery.
Although most things should work as is, libabigail will need to use a few new
interfaces to properly handle split dwarf, iterate through CUs using the new
dwarf_get_units, and change from using offsets and dwarf_dieoffset/dwarf_offdie
to using the new dwarf_die_addr_die interface (because DIEs can now come from
multiple files, so using offsets alone isn't enough to identify a DIE).
While we update libabigail for this could you try out the new elfutils-0.171
tools to see if they work correctly in your setup?
And could you indicate how important .dwp support is? Would a libabigail that
just works with .dwo files be enough for now?
The interfaces should be generic enough that when .dwp support is added to
elfutils libdw, then they should work as is and libabigail shouldn't really
care whether the split dwarf units come from the .dwo files or the .dwp package
file.
--
You are receiving this mail because:
You are on the CC list for the bug.
next prev parent reply other threads:[~2018-06-05 13:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-01 0:00 [Bug default/21023] New: " andrew.c.morrow at gmail dot com
2017-01-01 0:00 ` [Bug default/21023] " andrew.c.morrow at gmail dot com
2017-01-01 0:00 ` mark at klomp dot org
2017-01-01 0:00 ` mark at klomp dot org
2017-01-01 0:00 ` andrew.c.morrow at gmail dot com
2017-01-01 0:00 ` andrew.c.morrow at gmail dot com
2018-01-01 0:00 ` andrew.c.morrow at gmail dot com
2018-01-01 0:00 ` mark at klomp dot org [this message]
2021-12-06 22:12 ` tschwinge at sourceware dot org
2021-12-07 9:19 ` mark at klomp dot org
2021-12-07 9:29 ` mark at klomp dot org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-21023-9487-5YhhuzY6BX@http.sourceware.org/bugzilla/ \
--to=sourceware-bugzilla@sourceware.org \
--cc=libabigail@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).