thr3ads.net - llvm dev - [LLVMdev] Dropping the DW_ prefix from names in dwarfdump [Jan 2015]

If this information is useful, please help other people find it:
Share via:

Frédéric Riss

2015-Jan-19 18:42 UTC

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump

> On Jan 19, 2015, at 10:34 AM, David Blaikie <dblaikie at gmail.com>
wrote:
> 
> 
> 
> On Mon, Jan 19, 2015 at 10:29 AM, Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
> 
>> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at apple.com
<mailto:aprantl at apple.com>> wrote:
>> 
>> 
>>> On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at
gmail.com <mailto:dblaikie at gmail.com>> wrote:
>>> 
>>> Hey guys,
>>> 
>>> Frederic is introducing the expression dumping support and in the
interests of tersity is skipping the "DW_" in every "DW_OP"
(heck, we could even skip the "OP" given the context - nothing else
textual can appear there, right?)
> 
> I think it always depends on what you are debugging. When I’m interested
whether the encoding is correct, I think I’d prefer to have all these details in
there, even if they are redundant. When I’m debugging, e.g., the source location
associated with a function argument, I wouldn’t care about which Form is used to
encode the information.
> 
> Well all I was suggesting was dropping the prefixes - this wouldn't
result in any information loss, but possibly readability loss.
As I said in the review thread, I dropped the DW_ prefix for expressions as they
can be multiple of them on the same line. I have no strong feeling one way or
another for Attributes or Tags.
> apart from that, I think we could drop some verbosity too - just like we
now print constants, file/directory names, without their form, etc, etc - we
could probably do the same for strings (printing out the offset in the string
table all the time is mostly excessive) and probably other types. That would
actually be a loss of information that would certainly need a flag.
One of the next things I wanted to do was to drop the FORM display by default.
This would actually save a lot more horizontal space than the DW_ prefixes and
in my experience you nearly never need it. Of course there needs to be a flag to
get it back, because ‘nearly never’ ain’t ‘never :-).

Fred
>  
> 
> -- adrian
> 
>>> 
>>> Any thoughts on skipping the "DW_" (maybe even the
AT/TAG/FORM too) in the rest of dwarfdump? (skipping the AT/TAG (FORM would be
relatively easy I think) would be a bit trickier, but still
identifiable/solvable) I haven't tried it to see how it looks/reads.
>> 
>> I think we should have a switchable level of verbosity. I think that
the Darwin dwarfdump utility could serve as an example (at least to fuel the
discussion):
>> Here is Darwin's dwarfdump output with the default settings
>> 
>> ----------------------------------------------------------------------
>>  File: out.o (x86_64)
>> ----------------------------------------------------------------------
>> .debug_info contents:
>> 
>> 0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004 
abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0000005f)
>> 
>> 0x0000000b: TAG_compile_unit [1] *
>>              AT_producer( "clang version 3.5.0 (209308)" )
>>              AT_language( DW_LANG_C_plus_plus )
>>              AT_name( "test.cc <http://test.cc/>" )
>>              AT_stmt_list( 0x00000000 )
>>              AT_comp_dir( "/llvm_cmake" )
>>              AT_low_pc( 0x0000000000000000 )
>>              AT_high_pc( 0x00000184 )
>> 
>> 0x0000002a:     TAG_subprogram [2] *
>>                  AT_low_pc( 0x0000000000000000 )
>>                  AT_high_pc( 0x00000184 )
>>                  AT_frame_base( rbp )
>>                  AT_MIPS_linkage_name( "_Z3bari" )
>>                  AT_name( "bar" )
>>                  AT_decl_file( "/llvm_cmake/test.cc
<http://test.cc/>" )
>>                  AT_decl_line( 1 )
>>                  AT_type( {0x00000057} ( int ) )
>>                  AT_external( true )
>> 
>> 0x00000047:         TAG_formal_parameter [3]  
>>                      AT_location( 0x00000000
>>                         0x0000000000000000 - 0x00000000000000b9: rdi+0
>>                         0x00000000000000b9 - 0x0000000000000184:
rsp+16, deref )
>>                      AT_name( "y" )
>>                      AT_decl_file( "/llvm_cmake/test.cc
<http://test.cc/>" )
>>                      AT_decl_line( 1 )
>>                      AT_type( {0x00000057} ( int ) )
>> 
>> 0x00000056:         NULL
>> 
>> 0x00000057:     TAG_base_type [4]  
>>                  AT_name( "int" )
>>                  AT_encoding( DW_ATE_signed )
>>                  AT_byte_size( 0x04 )
>> 
>> 0x0000005e:     NULL
>> 
>> 
>> and here is the same file with -v:
>> 
>> ----------------------------------------------------------------------
>>  File: out.o {mach64-x86_64-MH_OBJECT} (x86_64)
>> ----------------------------------------------------------------------
>> .debug_info contents:
>> 
>> 0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004 
abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0000005f)
>> 
>> 0x0000000b: TAG_compile_unit [1] *
>> 0x0000000c:  AT_producer( .debug_str[0x00000000] = "clang version
3.5.0 (209308)" )
>> 0x00000010:  AT_language( 0x0004 ( DW_LANG_C_plus_plus ) )
>> 0x00000012:  AT_name( .debug_str[0x0000001d] = "test.cc
<http://test.cc/>" )
>> 0x00000016:  AT_stmt_list( 0x00000000 ( 0x00000000 ) )
>> 0x0000001a:  AT_comp_dir( .debug_str[0x00000025] =
"/llvm_cmake" )
>> 0x0000001e:  AT_low_pc( 0x0000000000000000 )
>> 0x00000026:  AT_high_pc( 0x00000184 )
>> 
>> 0x0000002a:     TAG_subprogram [2] *
>> 0x0000002b:      AT_low_pc( 0x0000000000000000 )
>> 0x00000033:      AT_high_pc( 0x00000184 )
>> 0x00000037:      AT_frame_base( <0x0000000000000001> 56  ( reg6 )
)
>> 0x00000039:      AT_MIPS_linkage_name( .debug_str[0x00000039] =
"_Z3bari" )
>> 0x0000003d:      AT_name( .debug_str[0x00000035] = "bar" )
>> 0x00000041:      AT_decl_file( 0x01 ( "/llvm_cmake/test.cc
<http://test.cc/>" ) )
>> 0x00000042:      AT_decl_line( 0x01 ( 1 ) )
>> 0x00000043:      AT_type( cu + 0x00000057 => {0x00000057} ( int ) )
>> 0x00000047:      AT_external( true )
>> 
>> 0x00000047:         TAG_formal_parameter [3]  
>> 0x00000048:          AT_location( 0x00000000
>>                         0x0000000000000000 - 0x00000000000000b9: breg5
+0
>>                         0x00000000000000b9 - 0x0000000000000184: breg7
+16, deref )
>> 0x0000004c:          AT_name( .debug_str[0x00000045] = "y" )
>> 0x00000050:          AT_decl_file( 0x01 ( "/llvm_cmake/test.cc
<http://test.cc/>" ) )
>> 0x00000051:          AT_decl_line( 0x01 ( 1 ) )
>> 0x00000052:          AT_type( cu + 0x00000057 => {0x00000057} ( int
) )
>> 
>> 0x00000056:         NULL
>> 
>> 0x00000057:     TAG_base_type [4]  
>> 0x00000058:      AT_name( .debug_str[0x00000041] = "int" )
>> 0x0000005c:      AT_encoding( 0x05 ( DW_ATE_signed ) )
>> 0x0000005d:      AT_byte_size( 0x04 )
>> 
>> 0x0000005e:     NULL
>> 
>> I particularly like the inline location expressions.
>> 
>> -- adrian
>> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/989836f8/attachment.html>

Eric Christopher

2015-Jan-19 18:54 UTC

head link

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump

On Mon Jan 19 2015 at 10:42:52 AM Frédéric Riss <friss at apple.com>
wrote:
> On Jan 19, 2015, at 10:34 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
>
> On Mon, Jan 19, 2015 at 10:29 AM, Adrian Prantl <aprantl at
apple.com> wrote:
>
>>
>> On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at
apple.com> wrote:
>>
>>
>> On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at
gmail.com> wrote:
>>
>> Hey guys,
>>
>> Frederic is introducing the expression dumping support and in the
>> interests of tersity is skipping the "DW_" in every
"DW_OP" (heck, we could
>> even skip the "OP" given the context - nothing else textual
can appear
>> there, right?)
>>
>>
>> I think it always depends on what you are debugging. When I’m
interested
>> whether the encoding is correct, I think I’d prefer to have all these
>> details in there, even if they are redundant. When I’m debugging, e.g.,
the
>> source location associated with a function argument, I wouldn’t care
about
>> which Form is used to encode the information.
>>
>
> Well all I was suggesting was dropping the prefixes - this wouldn't
result
> in any information loss, but possibly readability loss.
>
>
> As I said in the review thread, I dropped the DW_ prefix for expressions
> as they can be multiple of them on the same line. I have no strong feeling
> one way or another for Attributes or Tags.
>
> apart from that, I think we could drop some verbosity too - just like we
> now print constants, file/directory names, without their form, etc, etc -
> we could probably do the same for strings (printing out the offset in the
> string table all the time is mostly excessive) and probably other types.
> That would actually be a loss of information that would certainly need a
> flag.
>
>
> One of the next things I wanted to do was to drop the FORM display by
> default. This would actually save a lot more horizontal space than the DW_
> prefixes and in my experience you nearly never need it. Of course there
> needs to be a flag to get it back, because ‘nearly never’ ain’t ‘never :-).
>
>Like if you're looking for the actual enum constant ;)

That said, I like the ideas. I'm good with it.

Thanks!

-eric

> Fred
>
>
>
>>
>> -- adrian
>>
>>
>> Any thoughts on skipping the "DW_" (maybe even the
AT/TAG/FORM too) in
>> the rest of dwarfdump? (skipping the AT/TAG (FORM would be relatively
easy
>> I think) would be a bit trickier, but still identifiable/solvable) I
>> haven't tried it to see how it looks/reads.
>>
>>
>> I think we should have a switchable level of verbosity. I think that
the
>> Darwin dwarfdump utility could serve as an example (at least to fuel
the
>> discussion):
>> Here is Darwin's dwarfdump output with the default settings
>>
>> ----------------------------------------------------------------------
>>  File: out.o (x86_64)
>> ----------------------------------------------------------------------
>> .debug_info contents:
>>
>> 0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004
>> abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0000005f)
>>
>> 0x0000000b: TAG_compile_unit [1] *
>>              AT_producer( "clang version 3.5.0 (209308)" )
>>              AT_language( DW_LANG_C_plus_plus )
>>              AT_name( "test.cc" )
>>              AT_stmt_list( 0x00000000 )
>>              AT_comp_dir( "/llvm_cmake" )
>>              AT_low_pc( 0x0000000000000000 )
>>              AT_high_pc( 0x00000184 )
>>
>> 0x0000002a:     TAG_subprogram [2] *
>>                  AT_low_pc( 0x0000000000000000 )
>>                  AT_high_pc( 0x00000184 )
>>                  AT_frame_base( rbp )
>>                  AT_MIPS_linkage_name( "_Z3bari" )
>>                  AT_name( "bar" )
>>                  AT_decl_file( "/llvm_cmake/test.cc" )
>>                  AT_decl_line( 1 )
>>                  AT_type( {0x00000057} ( int ) )
>>                  AT_external( true )
>>
>> 0x00000047:         TAG_formal_parameter [3]
>>                      AT_location( 0x00000000
>>                         0x0000000000000000 - 0x00000000000000b9: rdi+0
>>                         0x00000000000000b9 - 0x0000000000000184:
rsp+16,
>> deref )
>>                      AT_name( "y" )
>>                      AT_decl_file( "/llvm_cmake/test.cc" )
>>                      AT_decl_line( 1 )
>>                      AT_type( {0x00000057} ( int ) )
>>
>> 0x00000056:         NULL
>>
>> 0x00000057:     TAG_base_type [4]
>>                  AT_name( "int" )
>>                  AT_encoding( DW_ATE_signed )
>>                  AT_byte_size( 0x04 )
>>
>> 0x0000005e:     NULL
>>
>>
>> and here is the same file with -v:
>>
>> ----------------------------------------------------------------------
>>  File: out.o {mach64-x86_64-MH_OBJECT} (x86_64)
>> ----------------------------------------------------------------------
>> .debug_info contents:
>>
>> 0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004
>> abbr_offset = 0x00000000  addr_size = 0x08  (next CU at 0x0000005f)
>>
>> 0x0000000b: TAG_compile_unit [1] *
>> 0x0000000c:  AT_producer( .debug_str[0x00000000] = "clang version
3.5.0
>> (209308)" )
>> 0x00000010:  AT_language( 0x0004 ( DW_LANG_C_plus_plus ) )
>> 0x00000012:  AT_name( .debug_str[0x0000001d] = "test.cc" )
>> 0x00000016:  AT_stmt_list( 0x00000000 ( 0x00000000 ) )
>> 0x0000001a:  AT_comp_dir( .debug_str[0x00000025] =
"/llvm_cmake" )
>> 0x0000001e:  AT_low_pc( 0x0000000000000000 )
>> 0x00000026:  AT_high_pc( 0x00000184 )
>>
>> 0x0000002a:     TAG_subprogram [2] *
>> 0x0000002b:      AT_low_pc( 0x0000000000000000 )
>> 0x00000033:      AT_high_pc( 0x00000184 )
>> 0x00000037:      AT_frame_base( <0x0000000000000001> 56  ( reg6 )
)
>> 0x00000039:      AT_MIPS_linkage_name( .debug_str[0x00000039] =
"_Z3bari"
>> )
>> 0x0000003d:      AT_name( .debug_str[0x00000035] = "bar" )
>> 0x00000041:      AT_decl_file( 0x01 ( "/llvm_cmake/test.cc" )
)
>> 0x00000042:      AT_decl_line( 0x01 ( 1 ) )
>> 0x00000043:      AT_type( cu + 0x00000057 => {0x00000057} ( int ) )
>> 0x00000047:      AT_external( true )
>>
>> 0x00000047:         TAG_formal_parameter [3]
>> 0x00000048:          AT_location( 0x00000000
>>                         0x0000000000000000 - 0x00000000000000b9: breg5
+0
>>                         0x00000000000000b9 - 0x0000000000000184: breg7
>> +16, deref )
>> 0x0000004c:          AT_name( .debug_str[0x00000045] = "y" )
>> 0x00000050:          AT_decl_file( 0x01 (
"/llvm_cmake/test.cc" ) )
>> 0x00000051:          AT_decl_line( 0x01 ( 1 ) )
>> 0x00000052:          AT_type( cu + 0x00000057 => {0x00000057} ( int
) )
>>
>> 0x00000056:         NULL
>>
>> 0x00000057:     TAG_base_type [4]
>> 0x00000058:      AT_name( .debug_str[0x00000041] = "int" )
>> 0x0000005c:      AT_encoding( 0x05 ( DW_ATE_signed ) )
>> 0x0000005d:      AT_byte_size( 0x04 )
>>
>> 0x0000005e:     NULL
>>
>> I particularly like the inline location expressions.
>>
>> -- adrian
>>
>>
>>
>-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/eee31d4c/attachment.html>

Robinson, Paul

2015-Jan-20 15:01 UTC

head link

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump

Hear hear.  DW_ adds no readability but AT_/TAG_/OP_/etc do.
Dropping the FORM entirely is fine; I view that as a mechanical encoding thing,
not relevant to the informational content.  If you're debugging the encoding
then it would matter, but for a random string-value attribute it really
doesn't matter which of the 3 (4?) different forms was used as long as the
actual string shows up correctly.
--paulr

From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On
Behalf Of Eric Christopher
Sent: Monday, January 19, 2015 10:54 AM
To: Frédéric Riss; David Blaikie
Cc: LLVM Developers Mailing List
Subject: Re: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump


On Mon Jan 19 2015 at 10:42:52 AM Frédéric Riss <friss at
apple.com<mailto:friss at apple.com>> wrote:
On Jan 19, 2015, at 10:34 AM, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:



On Mon, Jan 19, 2015 at 10:29 AM, Adrian Prantl <aprantl at
apple.com<mailto:aprantl at apple.com>> wrote:

On Jan 19, 2015, at 10:26 AM, Adrian Prantl <aprantl at
apple.com<mailto:aprantl at apple.com>> wrote:


On Jan 19, 2015, at 10:08 AM, David Blaikie <dblaikie at
gmail.com<mailto:dblaikie at gmail.com>> wrote:

Hey guys,

Frederic is introducing the expression dumping support and in the interests of
tersity is skipping the "DW_" in every "DW_OP" (heck, we
could even skip the "OP" given the context - nothing else textual can
appear there, right?)

I think it always depends on what you are debugging. When I’m interested whether
the encoding is correct, I think I’d prefer to have all these details in there,
even if they are redundant. When I’m debugging, e.g., the source location
associated with a function argument, I wouldn’t care about which Form is used to
encode the information.

Well all I was suggesting was dropping the prefixes - this wouldn't result
in any information loss, but possibly readability loss.

As I said in the review thread, I dropped the DW_ prefix for expressions as they
can be multiple of them on the same line. I have no strong feeling one way or
another for Attributes or Tags.


apart from that, I think we could drop some verbosity too - just like we now
print constants, file/directory names, without their form, etc, etc - we could
probably do the same for strings (printing out the offset in the string table
all the time is mostly excessive) and probably other types. That would actually
be a loss of information that would certainly need a flag.

One of the next things I wanted to do was to drop the FORM display by default.
This would actually save a lot more horizontal space than the DW_ prefixes and
in my experience you nearly never need it. Of course there needs to be a flag to
get it back, because ‘nearly never’ ain’t ‘never :-).


Like if you're looking for the actual enum constant ;)

That said, I like the ideas. I'm good with it.

Thanks!

-eric

Fred




-- adrian



Any thoughts on skipping the "DW_" (maybe even the AT/TAG/FORM too) in
the rest of dwarfdump? (skipping the AT/TAG (FORM would be relatively easy I
think) would be a bit trickier, but still identifiable/solvable) I haven't
tried it to see how it looks/reads.

I think we should have a switchable level of verbosity. I think that the Darwin
dwarfdump utility could serve as an example (at least to fuel the discussion):
Here is Darwin's dwarfdump output with the default settings

----------------------------------------------------------------------
 File: out.o (x86_64)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004  abbr_offset =
0x00000000  addr_size = 0x08  (next CU at 0x0000005f)

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "clang version 3.5.0 (209308)" )
             AT_language( DW_LANG_C_plus_plus )
             AT_name( "test.cc<http://test.cc/>" )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "/llvm_cmake" )
             AT_low_pc( 0x0000000000000000 )
             AT_high_pc( 0x00000184 )

0x0000002a:     TAG_subprogram [2] *
                 AT_low_pc( 0x0000000000000000 )
                 AT_high_pc( 0x00000184 )
                 AT_frame_base( rbp )
                 AT_MIPS_linkage_name( "_Z3bari" )
                 AT_name( "bar" )
                 AT_decl_file(
"/llvm_cmake/test.cc<http://test.cc/>" )
                 AT_decl_line( 1 )
                 AT_type( {0x00000057} ( int ) )
                 AT_external( true )

0x00000047:         TAG_formal_parameter [3]
                     AT_location( 0x00000000
                        0x0000000000000000 - 0x00000000000000b9: rdi+0
                        0x00000000000000b9 - 0x0000000000000184: rsp+16, deref )
                     AT_name( "y" )
                     AT_decl_file(
"/llvm_cmake/test.cc<http://test.cc/>" )
                     AT_decl_line( 1 )
                     AT_type( {0x00000057} ( int ) )

0x00000056:         NULL

0x00000057:     TAG_base_type [4]
                 AT_name( "int" )
                 AT_encoding( DW_ATE_signed )
                 AT_byte_size( 0x04 )

0x0000005e:     NULL


and here is the same file with -v:

----------------------------------------------------------------------
 File: out.o {mach64-x86_64-MH_OBJECT} (x86_64)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x0000005b  version = 0x0004  abbr_offset =
0x00000000  addr_size = 0x08  (next CU at 0x0000005f)

0x0000000b: TAG_compile_unit [1] *
0x0000000c:  AT_producer( .debug_str[0x00000000] = "clang version 3.5.0
(209308)" )
0x00000010:  AT_language( 0x0004 ( DW_LANG_C_plus_plus ) )
0x00000012:  AT_name( .debug_str[0x0000001d] =
"test.cc<http://test.cc/>" )
0x00000016:  AT_stmt_list( 0x00000000 ( 0x00000000 ) )
0x0000001a:  AT_comp_dir( .debug_str[0x00000025] = "/llvm_cmake" )
0x0000001e:  AT_low_pc( 0x0000000000000000 )
0x00000026:  AT_high_pc( 0x00000184 )

0x0000002a:     TAG_subprogram [2] *
0x0000002b:      AT_low_pc( 0x0000000000000000 )
0x00000033:      AT_high_pc( 0x00000184 )
0x00000037:      AT_frame_base( <0x0000000000000001> 56  ( reg6 ) )
0x00000039:      AT_MIPS_linkage_name( .debug_str[0x00000039] =
"_Z3bari" )
0x0000003d:      AT_name( .debug_str[0x00000035] = "bar" )
0x00000041:      AT_decl_file( 0x01 (
"/llvm_cmake/test.cc<http://test.cc/>" ) )
0x00000042:      AT_decl_line( 0x01 ( 1 ) )
0x00000043:      AT_type( cu + 0x00000057 => {0x00000057} ( int ) )
0x00000047:      AT_external( true )

0x00000047:         TAG_formal_parameter [3]
0x00000048:          AT_location( 0x00000000
                        0x0000000000000000 - 0x00000000000000b9: breg5 +0
                        0x00000000000000b9 - 0x0000000000000184: breg7 +16,
deref )
0x0000004c:          AT_name( .debug_str[0x00000045] = "y" )
0x00000050:          AT_decl_file( 0x01 (
"/llvm_cmake/test.cc<http://test.cc/>" ) )
0x00000051:          AT_decl_line( 0x01 ( 1 ) )
0x00000052:          AT_type( cu + 0x00000057 => {0x00000057} ( int ) )

0x00000056:         NULL

0x00000057:     TAG_base_type [4]
0x00000058:      AT_name( .debug_str[0x00000041] = "int" )
0x0000005c:      AT_encoding( 0x05 ( DW_ATE_signed ) )
0x0000005d:      AT_byte_size( 0x04 )

0x0000005e:     NULL

I particularly like the inline location expressions.

-- adrian



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150120/4da1a5d6/attachment.html>

llvm dev - Jan 2015 - [LLVMdev] Dropping the DW_ prefix from names in dwarfdump

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump

[LLVMdev] Dropping the DW_ prefix from names in dwarfdump