[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
Robinson, Paul
Paul_Robinson at playstation.sony.com
Tue Jan 20 09:29:03 PST 2015
Ø Why do you find that AT/TAG/OP adds to readability?
I'm usually not reading all of the dump output, I'm skimming it to find things in context, and my eye can easily pick out the uppercase TAG more easily than it can pick out a mumble_type in the middle of all that other lowercase text.
Ø From the context they should be pretty clear, I hope.
I'm not saying they add to the information content of the dump; clearly they don't. But they do make it easier to eyeball.
--paulr
From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Tuesday, January 20, 2015 9:12 AM
To: Robinson, Paul
Cc: Eric Christopher; Frédéric Riss; LLVM Developers Mailing List
Subject: Re: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump
On Tue, Jan 20, 2015 at 7:01 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto:Paul_Robinson at playstation.sony.com>> wrote:
Hear hear. DW_ adds no readability but AT_/TAG_/OP_/etc do.
Why do you find that AT/TAG/OP adds to readability?
From the context they should be pretty clear, I hope. TAGs have offset prefixes, attributes don't, and OPs appear inside attribute values, not at the top level. (I think of this like HTML - tag and attribute names don't have prefixes, they're just differentiated based on context)
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> [mailto: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/13886559/attachment.html>
More information about the llvm-dev
mailing list