Re: [PATCH][v2] Support .debug_macro

[Petr Machata <pmachata@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Mark Wielaard <mjw@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
another macro).

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
> between Dwarf_Macros.

Yeah.

> 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)?

*shrug*

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.

> http://dwarfstd.org/ShowIssue.php?issue=140724.1

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.

Thanks,
Petr