[LLVMdev] Dropping the DW_ prefix from names in dwarfdump (original) (raw)
David Blaikie dblaikie at gmail.com
Mon Jan 19 10:34:58 PST 2015
- Previous message: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump
- Next message: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 "DWOP" (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.
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.
-- 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 (x8664) ---------------------------------------------------------------------- .debuginfo contents: 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbroffset = 0x00000000 addrsize = 0x08 (next CU at 0x0000005f) 0x0000000b: TAGcompileunit [1] * ATproducer( "clang version 3.5.0 (209308)" ) ATlanguage( DWLANGCplusplus ) ATname( "test.cc" ) ATstmtlist( 0x00000000 ) ATcompdir( "/llvmcmake" ) ATlowpc( 0x0000000000000000 ) AThighpc( 0x00000184 ) 0x0000002a: TAGsubprogram [2] * ATlowpc( 0x0000000000000000 ) AThighpc( 0x00000184 ) ATframebase( rbp ) ATMIPSlinkagename( "Z3bari" ) ATname( "bar" ) ATdeclfile( "/llvmcmake/test.cc" ) ATdeclline( 1 ) ATtype( {0x00000057} ( int ) ) ATexternal( true ) 0x00000047: TAGformalparameter [3] ATlocation( 0x00000000 0x0000000000000000 - 0x00000000000000b9: rdi+0 0x00000000000000b9 - 0x0000000000000184: rsp+16, deref ) ATname( "y" ) ATdeclfile( "/llvmcmake/test.cc" ) ATdeclline( 1 ) ATtype( {0x00000057} ( int ) ) 0x00000056: NULL 0x00000057: TAGbasetype [4] ATname( "int" ) ATencoding( DWATEsigned ) ATbytesize( 0x04 ) 0x0000005e: NULL and here is the same file with -v: ---------------------------------------------------------------------- File: out.o {mach64-x8664-MHOBJECT} (x8664) ---------------------------------------------------------------------- .debuginfo contents: 0x00000000: Compile Unit: length = 0x0000005b version = 0x0004 abbroffset = 0x00000000 addrsize = 0x08 (next CU at 0x0000005f) 0x0000000b: TAGcompileunit [1] * 0x0000000c: ATproducer( .debugstr[0x00000000] = "clang version 3.5.0 (209308)" ) 0x00000010: ATlanguage( 0x0004 ( DWLANGCplusplus ) ) 0x00000012: ATname( .debugstr[0x0000001d] = "test.cc" ) 0x00000016: ATstmtlist( 0x00000000 ( 0x00000000 ) ) 0x0000001a: ATcompdir( .debugstr[0x00000025] = "/llvmcmake" ) 0x0000001e: ATlowpc( 0x0000000000000000 ) 0x00000026: AThighpc( 0x00000184 ) 0x0000002a: TAGsubprogram [2] * 0x0000002b: ATlowpc( 0x0000000000000000 ) 0x00000033: AThighpc( 0x00000184 ) 0x00000037: ATframebase( <0x0000000000000001> 56 ( reg6 ) ) 0x00000039: ATMIPSlinkagename( .debugstr[0x00000039] = "Z3bari" ) 0x0000003d: ATname( .debugstr[0x00000035] = "bar" ) 0x00000041: ATdeclfile( 0x01 ( "/llvmcmake/test.cc" ) ) 0x00000042: ATdeclline( 0x01 ( 1 ) ) 0x00000043: ATtype( cu + 0x00000057 => {0x00000057} ( int ) ) 0x00000047: ATexternal( true ) 0x00000047: TAGformalparameter [3] 0x00000048: ATlocation( 0x00000000 0x0000000000000000 - 0x00000000000000b9: breg5 +0 0x00000000000000b9 - 0x0000000000000184: breg7 +16, deref ) 0x0000004c: ATname( .debugstr[0x00000045] = "y" ) 0x00000050: ATdeclfile( 0x01 ( "/llvmcmake/test.cc" ) ) 0x00000051: ATdeclline( 0x01 ( 1 ) ) 0x00000052: ATtype( cu + 0x00000057 => {0x00000057} ( int ) ) 0x00000056: NULL 0x00000057: TAGbasetype [4] 0x00000058: ATname( .debugstr[0x00000041] = "int" ) 0x0000005c: ATencoding( 0x05 ( DWATEsigned ) ) 0x0000005d: ATbytesize( 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/72e959e8/attachment.html>
- Previous message: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump
- Next message: [LLVMdev] Dropping the DW_ prefix from names in dwarfdump
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]