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
