This is the mail archive of the
elfutils-devel@sourceware.org
mailing list for the elfutils project.
Re: [PATCH][v2] Support .debug_macro
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Wed, 01 Oct 2014 12:06:05 +0200
- Subject: Re: [PATCH][v2] Support .debug_macro
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