David Blaikie
2015-Jan-19 18:08 UTC
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
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?) 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150119/f7bdd7bd/attachment.html>
Adrian Prantl
2015-Jan-19 18:26 UTC
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
> 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?) > > 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/95d46a9d/attachment.html>
Adrian Prantl
2015-Jan-19 18:29 UTC
[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
> 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 <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. -- 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/3f109cd0/attachment.html>