[LLVMdev] Dropping the DW_ prefix from names in dwarfdump
David Blaikie
dblaikie at gmail.com
Tue Jan 20 09:11:54 PST 2015
On Tue, Jan 20, 2015 at 7:01 AM, Robinson, Paul <
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] *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> 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/20150120/19c82aa3/attachment.html>
More information about the llvm-dev
mailing list