On 07/21/2011 04:22 AM, Jakub Jelinek wrote: > Currently, the patch emits 3 byte section headers at the start of > the .debug_gnu_macro chunks referenced from .debug_info (through > DW_AT_GNU_macros), containing version number (2 byte, 4 ATM) and > 1 byte section offset, but the DW_GNU_MACRO_transparent_include > referenced sequences don't have it. > The .debug_gnu_macro section isn't completely usable without the referencing > CUs anyway, so IMHO we could still get away completely without > any section header, but if we need it, the question is if > the offset size there is useful and if the section header shouldn't > go before the transparent_include chains as well (only with that > e.g. readelf -wm would be able to dump .debug_gnu_macro without > reading .debug_info and tracking offsets to it).
I've been wondering if the header shouldn't contain the opcode definitions, similar to .debug_line, and drop your _define_opcode. It does mean that you couldn't re-define opcodes within any one sequence, but does that actually seem useful? Defining the opcodes in the header makes it clear that there should be a header for the include sequences, and that makes it clear that the defined opcodes are local to a given sequence, without having to have awkward wording as for _define_opcode. I do like mjw's idea of using the version number to distinguish our implementation and one with the dwarf5 stamp of approval. This suggests going ahead with .debug_macro as the section name. > In x86_64 cc1plus for which I've been posting figures, I see > 395 CUs referencing .debug_gnu_macro and at most 511 different > .debug_gnu_macro chains with unique md5sums. So, the cost of the > 3 byte headers is for cc1plus just in CU referenced chunks > 1185 bytes, 3 byte headers in all .debug_gnu_macro chunks > 2718 bytes. Putting the opcode definitions into the header would increase the overhead more, somewhere between 12 and 20 bytes per chain. Which is, I think still manageable. > Also, should the decision whether to emit .debug_gnu_macro or .debug_macinfo > depend on -gdwarf-strict, or should we have a separate switch for that? I'm fine with strict. Anyone else have an opinion? r~
