Re: patch: improve decode-to-name of additional DWARF 2/DWARF 3 codes

[Jim Blandy <jimb at codesourcery dot com>]

"Gary Funck" <gary@intrepid.com> writes:
> [I'm resubmitting this patch, incorporating Jim Blandy's
> suggestions.  I think the copyright assignment issues have
> been straightened out.  If not, please let me know off list.]
>
> While debugging GDB, I noticed the routines in dwarf2read.c that
> decode DWARF 2 and DWARF 3 codes into their corresponding string
> names have not been updated to include the various encodings
> that have been added over the past few years.  This primarily
> impacts the diagnostic output that assists when debugging GDB.
>
> Attached is a suggested patch (to gdb 6.5), which brings the
> various *_name routines up to date with the definitions
> in include/elf/dwarf2.h.

This looks great; please go ahead and commit.  Thanks for all your
patience.

> There is a small problem in the decoding caused by the
> following (in dwarf2.h):
>
>     /* GNU extensions.  */
>     DW_OP_GNU_push_tls_address = 0xe0,
>     /* HP extensions.  */
>     DW_OP_HP_unknown     = 0xe0, /* Ouch, the same as GNU_push_tls_address.
> */
>
> I arbitrarily chose to decode 0xe0 as "DW_OP_GNU_push_tls_address".

I think that's the best we can do in these situations.

What's important is that the name decoded actually match how GDB will
interpret it; since GDB recognizes the push_tls_address operation, but
not the 'HP_unknown', that's the way it should print it.  If GDB ever
did something fancy like look at the compilation unit's producer and
distinguish opcodes on that basis, then the printer would need to do
the same.

> Also, I preserved the "#ifdef MIPS" inside dwarf_attr_name(), but
> it wasn't clear to me that it is needed.  If it is, then for
> consistency, perhaps ifdef's for HP, GNU, DWARF3, and other
> extensions to DWARF 2 would also be required.

If the values don't conflict, I think it's best to go ahead and
recognize all of them.  Where they do conflict, the argument above
applies.