On Tue, 2014-09-30 at 18:06 +0200, Petr Machata wrote:
> Mark Wielaard <mjw@redhat.com> writes:
> > The question is does the user of Dwarf_Macro need them? The user isn't
> > going to check against the version, they are just matching against the
> > DW_MACRO constants and for interpreting the arguments and file names
> > they will use the attribute and helper functions provided.
> 
> The user needs at least the .debug_line offset, if they are supposed to
> handle any start_file-like opcodes.  But I noticed we don't even have a
> function like dwarf_offline, or dwarf_offsrcfiles, which I just assumed
> would be present.  So the offset itself is not really useful anyway.

Ah, I missed that what is provided is a "File" not just a file name. I
see why this was probably not an issue for macinfo. Since those are
explicitly associated with a specific CU. So you would get the files
from there. But macro tables are more generic and carry their own file
list (reference).

> I think the way forward then is to have an interface like this:
> 
> extern int dwarf_macro_srcfiles (Dwarf_Macro *macro, Dwarf_Files **files,
> 				 size_t *nfiles)
> 
> ... this would return the files-section associated with the macro unit.
> The user could then use the usual interfaces to query the files section
> however they like.  I would like such interface betten than one that
> works akin to dwarf_macro_param*, because it's more general.  There's no
> telling where the file number comes from, it might be implied by the
> opcode for all I care.

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

BTW. There is a proposal for DWARF5 to extend the line file table with
vendor extensions to describe more properties like with macros, but it
is a little unclear what the current status is. There are multiple
proposals that seem to have been (dis|re)approved. And sadly most of
them seem not to have been publicly proposed or discussed. See
http://dwarfstd.org/ShowIssue.php?issue=140724.1
And it isn't really related to this macro table interface. Just a
pointer that we might need a similar cleanup of file tables as we do now
for macros. Hopefully we can reuse some of the param/form/attribute
design.

Thanks,

Mark