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 ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
