Mark Wielaard <mjw(a)redhat.com> writes:
On Tue, 2014-09-30 at 18:06 +0200, Petr Machata wrote:
> extern int dwarf_macro_srcfiles (Dwarf_Macro *macro, Dwarf_Files **files,
> size_t *nfiles)
Yeah, this interface is nicer than trying to describe the file entry
with attributes/forms. And it mimics what we have for CUs. So all file
accessors/helper functions work just the same. The one difference is
that for CUs we only make it work on the CU Dwarf_Die, not all
Dwarf_Dies in the CU. So we will have to make it clear what we expect
the user to do here.
The cleanest solution would probably be to expose the existence of macro
units to the user. Fundamentally, things like versions, file tables and
even macro prototypes are associated with macro units. Presenting them
in any other way risks there will be impedance mismatch (like having to
ask whether a Files pointer obtained through one macro is still valid in
But this smells of overengineering. We would then have Dwarf macro
units, Dwarf macros and Dwarf macro prototypes, which is a lot of
concepts for something that few clients care about (essentially only
dwgrep does, I expect).
I assume it makes most sense/is the most flexible
to allow the user to call it on every Dwarf_Macro and to make no
promises about whether the Dwarf_Files returned are cached/related
Or is there a case to be made for the user to cache the
dwarf_macro_srcfiles result between processing different Dwarf_Macros
(and should we warn for/against users depending on them being the same
if they know the Dwarf_Macros come from the same macros table/header)?
A point could be made that individual opcodes could set a different file
section (say, DW_MACRO_push_lineoff, DW_MACRO_pop_lineoff), so that's
somewhat hazy argument against caching. Then again this argument just
illustrates that we should have had dwarf_offsrcfiles all along, as that
better reflects the underlying reality of Dwarf.
For now I'd just ban caching, because that's what we do with these sorts
of interfaces. Principle of least surprise and all that.
Hmm, interesting. We'll have to wait until what appears in one of the
Dwarf 5 drafts.
Hopefully we can reuse some of the param/form/attribute design.
Yep, that would be cool.