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
[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
[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>
Seemingly Similar Threads
- [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] DW_AT_location not getting generated for local variables
- [LLVMdev] DW_AT_location not getting generated for local variables