From: Petr Machata <pmachata@redhat.com>
To: elfutils-devel@lists.fedorahosted.org
Subject: Transparent imports of partial units
Date: Tue, 14 Oct 2014 02:24:48 +0200 [thread overview]
Message-ID: <m2siirjy5r.fsf@redhat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]
Hi there,
with dwz out there in the wild and being used, clients will generally
have to deal with handling of partial units. (They always kinda had to,
but now they have to for real.) In theory, every time that you call
dwarf_child or dwarf_siblingof, you should do a little dance of checking
whether the DIE happens to be DW_TAG_imported_unit, and if yes, locate
that unit and look at its children, possibly recursively resolving more
imported units. You then should retract along the same lines when
dwarf_siblingof hits the wall.
It seems inefficient to have to replicate this logic in each client. We
have interfaces for transparent integration of attributes, why not do
something similar for partial unit imports? Currently partial units are
only handled in __libdw_visit_scopes.
I don't have any particular plan, but at least dwarf_child and
dwarf_siblingof seem like they shoud have transparent-importing twins.
My abstract ideas count on caching DIE's of the integration points and
referencing them through the now-unused padding field of Dwarf_Die.
Then when dwarf_siblingof hits the end of DIE chain, it checks this
field and possibly continues the iteration there.
On top of the above, there are places in libdw where dwarf_child and
dwarf_siblingof are called. E.g. in dwarf_aggregate_size, there could
in theory be an import point between DW_TAG_enumeration_type and its
DW_TAG_enumerator's. That's not currently handled. It seems like in
these sorts of cases, we should use the new interfaces.
Opinions?
Thanks,
Petr
next reply other threads:[~2014-10-14 0:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-14 0:24 Petr Machata [this message]
2014-10-31 14:40 Mark Wielaard
2014-10-31 18:26 Petr Machata
2014-10-31 22:48 Josh Stone
2014-11-07 14:08 Mark Wielaard
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=m2siirjy5r.fsf@redhat.com \
--to=pmachata@redhat.com \
--cc=elfutils-devel@lists.fedorahosted.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).