[Dwarf-Discuss] Vendor extensions in .debug_macinfo

[Jakub Jelinek]

Hi!

The current .debug_macinfo format isn't very much extensible
and is not really designed to allow reducing of duplicate debug
info, so when compilers want to produce maco information, size
of .debug_macinfo is prohibitive.

We are discussing some extensions that would allow us to reduce
the size of the macinfo hundredfolds while preserving all information
it contains, see
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01070.html
but as .debug_macinfo in DWARF{2,3,4} currently defines just
0 opcode as terminator, 4 standard opcodes and an unusable vendor
extension opcode (the arguments are DW_FORM_udata (or sdata) and
DW_FORM_string, both need to be specified, but the string
is zero terminated and thus can't accomodate arbitrarily encoded operands
and the uleb128 constant operand can't accomodate e.g. section offsets,
because they need to be fixed size (4byte or 8 byte, so that relocations
can be applied there), I'd like to ask if it would be possible for the
upcoming DWARF to reserve a range of DW_MACINFO_* opcodes for vendor
purposes, say DW_MACINFO_lo_user 0xe0 through DW_MACINFO_hi_user 0xfe.
Debug info consumers which would encounter opcodes they don't support
(be it in this range or in the standard reserved range) would just need to
give up on parsing that .debug_macinfo sequence, which is unfortunate of
course, but e.g. the above proposal has an opcode to allow for future
extensions that would allow consumers to skip the unknown opcodes if they
are documented through the special new opcode.
If this works out, we would of course like to propose the extensions later
on for DWARF5 in a standard opcode range.

So, is this acceptable or do we need to just use different section
names (.debug_gnu_macinfo) and use different, vendor DW_AT_GNU_macro_info
attributes to point into that section, and stop producing .debug_macinfo)?

	Jakub