Jakub Jelinek <ja...@redhat.com> writes:
> 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
So the problem that I'm talking about is this: imagine there's a bunch
of DW_MACINFO_vendor_ext extensions somewhere in the wild. The vendor
would naturally map those to the new-style section, each extension would
get it's own DW_MACRO_FOO_* opcode, and eventually DW_MACRO_hi_user gets
allocated as well (as DW_MACRO_FOO_frobnicate, and it just happens to
have a numeric and a string parameter).
At this point, 0xff double-serves as either DW_MACINFO_vendor_ext (in
which case the first parameter is vendor opcode and the second is
whatever), or DW_MACRO_FOO_frobnicate (in which case the first parameter
is, say, frobnicator salt and second is whatever).
For this reason a library that decodes .debug_macinfo can't simply
transparently switch to .debug_macro, because some client might
misinterpret 0xff as DW_MACINFO_vendor_ext, even if what we mean is
DW_MACRO_FOO_frobnicate. The client could use other means to
disambiguate the situation, but a .debug_macinfo client wouldn't know
it's supposed to.
This is the only opcode with this problem. Others would be handled by
whatever means the client has for handling unsupported opcodes, most
likely by bailing out or ignoring them.
> 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.
There's not much difference actually.
E.g. take DW_MACRO_define. The standard doesn't mention what form its
first argument should have (should I open another issue for this?). We
"know" it's DW_FORM_udata, because "that's how it has always been" (plus
it makes sense), but if that opcode is not described in the prototype
table, I formally don't know how to decode it.
Now if the table does mention that opcode, what if, instead of
DW_FORM_string for its second argument, it uses DW_FORM_strp? Or if it
adds a third argument? I mean, why not? What's the harm? It makes no
sense, but per my reading, it is valid. And I'd better use that
information when decoding the section, otherwise garbage comes out. And
if the extra arguments can be safely ignored by the client, that's not
even a problem.
So parsing and serving vendor extensions is largely not different from
parsing and serving standard opcodes.
What a client does with what I serve is their problem. If we are
talking about a readelf-like application, then showing the overlapping
part of DW_MACRO_* as DW_MACINFO_* is no problem at all, as the
semantics are the same. Unless we talk about 0xff, which would throw
this client off, because what 0xff means in DW_MACRO_* world is
extremely likely not what it means in DW_MACINFO_* world.
Similarly a client that knows about DW_MACRO_* can just interpret all
DW_MACINFO_* opcodes as DW_MACRO_* ones and not be worried that it puts
anyone into great confusion. Except for 0xff.
None of this is technical problem. We can add new interfaces, add
version-querying, etc., that's all fine. But reserving 0xff would allow
us to keep existing interfaces instead of having to invent new ones to
protect extant clients.
Thanks,
Petr
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
