[Dwarf-Discuss] Vendor extensions in .debug_macinfo

[Michael Eager]

On 07/20/2011 11:00 AM, Jakub Jelinek wrote:
> On Wed, Jul 20, 2011 at 10:16:10AM -0700, Michael Eager wrote:
>> It took me a few days to review the current DWARF macinfo specification
>> and review this proposal.
>>
>> The existing macro data format is clearly in need of revision.   I don't
>> think that there is any way to modify this format which would be transparent
>> and usable by a consumer which expected the current format.
>>
>> I recommend that you create a new section to contain this data, perhaps
>> .debug_macinfo2 or .debug_macro.  Create a file header which includes at a
>> minimum a version number, similar to the other DWARF data sections.
>> This will give more flexibility in defining the contents of the section.
>
> Yeah, this is the other option I was giving, one was modifying the existing
> .debug_macinfo and the other option is coming up with a new section format.
>
>> Define new macinfo opcodes as in your proposal (you can number them from 0x01).
>> Rather than using either the existing DW_MACINFO_vendor_ext opcode or your
>> DW_MACINFO_GNU_define_opcode for vendor extensions, I would define a vendor
>> extension range using the same *_lo_user and *_hi_user scheme used in other
>> parts of DWARF.
>
> Well, one thing is extension range for vendor extensions and the other is
> how to teach consumers about what arguments the new opcodes have.  The
> define_opcode op was meant like an embedded abbrev which would specify the
> argument encodings, which is still useful.  Of course vendor_ext opcode
> would be useless in that case.
>
>>   Actually, I would suggest that GCC not implement a vendor
>> extension scheme at this time,
>
> If we go the new section way, then surely the initial ops would be all
> non-vendor extensions.
>
>> but wait until the DWARF committee has had an
>> opportunity to review the proposal and incorporate it into a future version
>> of DWARF.  Should you discover a need for an additional opcode, simply add
>> it to the implementation.
>
> I'm afraid we don't want to wait a few years for DWARF5 though, we need
> this right now, which is why if DWARF committee preference is a new section,
> I think we should introduce .debug_gnu_macro section and keep it as whole
> as a GNU extension and propose .debug_macro section with the same content
> for DWARF5.  Then, if DWARF5 uses the same format, perfect, if it uses a
> different one, the consumers could just choose to support both formats or
> something and GCC as a producer would phase the GNU extension format out.

Sorry if I was not clear.  I was only referring to deferring implementation
of the vendor extension opcode, not the new data section.

>
>> The DW_AT_macro_info attribute would be a section offset into either
>> .debug_macinfo or .debug_macro, depending on which was present.
>
> That won't work, you need different attributes, because DW_FORM_sec_offset
> is relative to the start of the section, but doesn't say which (in ELF
> .debug* sections have all 0 as starting address).  If DW_AT_macro_info
> value was .debug_macinfo, .debug_macro or .debug_gnu_macro section index
> depending on which of the 3 sections is present, any time you link together
> objects compiled with different compilers and one e.g. produces
> .debug_macinfo, one .debug_gnu_macro, then both sections will be present and
> it is unclear in each of the CUs what section is DW_AT_macro_info refering
> to.

You are right.  A new attribute is required.

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