[Dwarf-Discuss] Vendor extensions in .debug_macinfo
eager at eagercon.com
Wed Jul 20 11:07:31 PDT 2011
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
You are right. A new attribute is required.
Michael Eager eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Dwarf-Discuss