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
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
