Re: [RFC] More compact (100x) -g3 .debug_gnu_macro (take 4)

[Richard Henderson <rth at redhat dot com>]

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~