Re: [Dwarf-Discuss] Vendor extensions in .debug_macinfo

[Jakub Jelinek <jakub at redhat dot com>]

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.

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

> I think that your modifications would be a significant improvement to DWARF.
> Please submit a proposal at http://dwarfstd.org/Comment.php.

Sure.

	Jakub