[Dwarf-Discuss] Vendor extensions in .debug_macinfo

[Michael Eager]

On 07/21/2011 04:36 AM, Jakub Jelinek wrote:
> On Wed, Jul 20, 2011 at 01:17:57PM -0700, David Anderson wrote:
>> On 07/20/2011 01:07 PM, David Anderson wrote:
>>>
>>> On the other hand,  I have not seen the detailed proposal, so
>>> perhaps that proposal
>
> The previous proposal (the one adding opcodes to the current
> .debug_macinfo instead of creating a new section) was worded roughly in
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01284.html
>
> In http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01736.html
> is a rough implementation of .debug_gnu_macro section and
> DW_AT_GNU_macros referencing it.
>
> Here are rough DWARF4 edits for this.
> I'm not sure in what way should the old .debug_macinfo be
> deprecated in DWARF5, the following edits describe both the
> .debug_macro section and .debug_macinfo too, and refer to the
> latter as legacy.  Another option I guess would be to document
> in DWARF5 only .debug_macro section and just in DW_AT_macro_info
> description say that it doesn't refer to .debug_macro section,
> but instead to legacy .debug_macinfo as defined in DWARF2 through DWARF4
> and other than that don't document .debug_macinfo at all, in appendix
> F it would have a rows like:
> .debug_macinfo	-	-	-	x
> .debug_macro	x	x	x	5
> then.  What do you prefer?

There are pros and cons to deprecation vs removal of the .debug_macinfo
section.  I think that this is something the DWARF committee will need to
discuss.

There's no need to address this in your proposal.  Just describe a replacement
for .debug_macinfo.  If we decide to include both formats in a future version
of DWARF, we will address this as an editorial issue.

> Also, regarding the section headers, I'm still not convinced they are
> particularly useful, as .debug_macro is only useful with the corresponding
> referencing .debug_info which has its own version number.  But if you think
> it is useful, should it be in front of all .debug_macro chunks (even the
> transparent include chains)?  And, should it include the offset size
> or is that unnecessary?  With the section headers everywhere and offset size
> everywhere some tools could parse/display .debug_macro content even without
> parsing referencing .debug_info, just it couldn't give meaning to start_file
> filenames (translate the constant into filename string).  Without them it
> can't and would need to handle it e.g. similarly how .debug_loc needs to be
> handled in such tools.  As the msg01736.html URL above refers to,
> in the test binary from the compiler itself, there are 395 DW_AT_GNU_macros
> attributes and 511 unique DW_GNU_MACRO_transparent_include chains, so
> the size of 3 byte headers for 395+511 chunks is<  3KB for the ~ 1MB size
> of .debug_gnu_macro, i.e. .3%.

We have a header for almost every data section.  Unless there is a compelling
argument why this particular section should not have one, I believe that we
will include one in any new macro data description.  I do not see that the
macro description is specifically tied in a one-to-one relationship with the
.debug_info section.  In a hypothetical future revision (say DWARF version 6)
we could make changes to the .debug_info section without making changes to
the macro description.  Conversely, at some future date the macro description
could be extended in some (currently unknown) incompatible manner which did not
require changes to the .debug_info format.

We generally have a header before the data from each compilation unit.  Fields
like a reference to the offset of the compilation unit or the offset to the next
set of data in the section are designed to make it easier for a consumer to read
and process a data section incrementally, and, ideally, with little or no reference
to other sections.  Any particular consumer may ignore these fields, preferring to
read all of the data at one time.

I can't comment on your questions about transparent include chains or other details.
Do what you think works best.

Thank you for your detailed proposal.   Please submit the proposed changes at
http://dwarfstd.org/Comment.php.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077