[Dwarf-Discuss] Proposal to reserve .debug_macro opcode 0xff

[Jakub Jelinek]

On Wed, Oct 01, 2014 at 01:30:46AM +0200, Petr Machata wrote:
> Hello,
> 
> I'm working on support in elfutils for the .debug_macro proposal[1].
> 
> The numerical values and semantics of DW_MACINFO_* opcodes are
> equivalent to their new-style DW_MACRO_* counterparts.  So a decoder
> could transparently read in .debug_macro instead of .debug_macinfo, and
> serve the opcodes found there to a client, without fear that they get
> misinterpreted.
> 
> Were it not for DW_MACINFO_vendor_ext, 0xff.  This value, in new-style
> sections, is part of the vendor extension block, as DW_MACRO_hi_user.
> It could be allocated and emitted, and a client would misinterpret it as
> DW_MACINFO_vendor_ext, decode it, and make decisions based on this
> misinterpretation.
> 
> I would therefore like to propose that the opcode 0xff is considered
> reserved, and DW_MACRO_hi_user is changed to 0xfe.
> 
> Does this sound reasonable?  Should I file an issue for this?
> 
> [1] http://www.dwarfstd.org/ShowIssue.php?issue=110722.1

All of values from DW_MACRO_lo_user to DW_MACRO_hi_user are meant for
vendor extensions and can have arbitrary arguments, I doubt
the particular one (with an integer and inline string argument)
is useful for anything.  If a vendor needs an extension with a string
argument, it is much better to either encode the constant in the
DW_MACRO_lo_user + constant opcode and just use DW_FORM_strp (not
DW_FORM_string) argument, or use DW_FORM_udate, DW_FORM_strp
arguments.  For DW_MACRO_{lo,hi}_user values you need to handle
them specially, not pass them through, any case, because you need
to read the description of their arguments and print them likely
as DW_MACRO_lo_user+%02x or similar.

	Jakub