search for: at_name

...: 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] * >...

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

...b 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_su...

...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( 0x0000000000...

...000000: Compile Unit: length = 0x000000a9 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x000000ad) 0x0000000b: TAG_compile_unit [1] * AT_producer( "clay compiler 0.1git" ) AT_language( Unknown DW_LANG constant: 0xc1a4 ) AT_name( "foo.clay" ) AT_entry_pc( 0x0000000000000000 ) AT_stmt_list( 0x00000000 ) 0x00000038: TAG_namespace [2] * AT_sibling( {0x0000005c} ) AT_name( "__main__" ) AT_decl_file( "/Users/joe/Documents/...

On Apr 7, 2011, at 12:14 PM, Talin wrote: > > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.String)" ) > 0x000000d0: AT_decl_file( 0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.ta...

...= 0x000000a9  version = 0x0002  abbr_offset > = 0x00000000  addr_size = 0x08  (next CU at 0x000000ad) > > 0x0000000b: TAG_compile_unit [1] * >              AT_producer( "clay compiler 0.1git" ) >              AT_language( Unknown DW_LANG constant: 0xc1a4 ) >              AT_name( "foo.clay" ) >              AT_entry_pc( 0x0000000000000000 ) >              AT_stmt_list( 0x00000000 ) > > 0x00000038:     TAG_namespace [2] * >                  AT_sibling( {0x0000005c} ) >                  AT_name( "__main__" ) >                  AT_decl...

Hi,   I want to list some additional information on this.   The variable collection I am looking at is, "variables 'declared' in scope".   1. When I traverse the MachineInstructions in the LexicalScopes ranges, and check for variables, I get variables used in this scope.      The variables listed include variables which may not have been declared in the scope. (for example

...-------- .debug_info contents: 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) 0x0000000b: TAG_compile_unit [1] * AT_producer( "volta" ) AT_language( DW_LANG_C99 ) AT_name( "a.c" ) AT_entry_pc( 0x0000000000000000 ) AT_stmt_list( 0x00000000 ) AT_comp_dir( "/Users/mmp/foo" ) AT_APPLE_optimized( 0x01 ) AT_APPLE_flags( "-g" ) 0x00000039: TAG_subprogram [2]...

...> 0x00000000: Compile Unit: length = 0x00000045 version = 0x0003 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000049) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "julia" ) > AT_language( DW_LANG_C89 ) > AT_name( "string.jl" ) > AT_stmt_list( 0x00000000 ) > AT_comp_dir( "." ) > AT_APPLE_optimized( 0x01 ) > AT_low_pc( 0x0000000112f5f1c0 ) > AT_high_pc( 0x000006fb ) > > 0x0000002b: TAG_subprogram [2...

...>> debugger and see why it is not reaching to DwarfDebug::emitDIE(). >> > > OK I've been checking this out some more, and the DIEs don't look valid to > me. Take a look at this output from dwarfdump -v: > > 0x000000c7: TAG_subprogram [3] > 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) > 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = > "tart.reflect.Parameter.construct(tart.core.String)" ) > 0x000000d0: AT_decl_file( 0x3d ( > "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Pa...

...83 and set appropriate breakpoint in > debugger and see why it is not reaching to DwarfDebug::emitDIE(). > OK I've been checking this out some more, and the DIEs don't look valid to me. Take a look at this output from dwarfdump -v: 0x000000c7: TAG_subprogram [3] 0x000000c8: AT_name( .debug_str[0x000001bd] = "construct" ) 0x000000cc: AT_MIPS_linkage_name( .debug_str[0x000001c7] = "tart.reflect.Parameter.construct(tart.core.String)" ) 0x000000d0: AT_decl_file( 0x3d ( "/Users/talin/Projects/tart/trunk/lib/std/tart/reflect/Parameter.tart" )...

...ns have >>>> 'Addend' in the entry, but there's no 'Addend' info in bpf elf >>>> file(64bit). I think there must be something wrong in the process >>>> of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the >>>> AT_name now, DW_AT_LOCATION still missed and need your help. >>> Another thing about DW_AT_name, we've already found that the name string is stored indirectly and needs relocation which is architecture specific, while the e_machine info in bpf obj file is "unknown", both objdump and...

I didn't get to work on this more last week, but I'll look at incorporating that suggestion. The other question of course is how to do this in LLDB. Right, now what I'm doing is going through and adjusting the load address of every leaf in the section tree. That basically works and gets me backtraces with the correct function names and the ability to set breakpoints at functions in

...gt; > 0x00000000: Compile Unit: length = 0x00000043 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x08 (next CU at 0x00000047) > > 0x0000000b: TAG_compile_unit [1] * > AT_producer( "volta" ) > AT_language( DW_LANG_C99 ) > AT_name( "a.c" ) > AT_entry_pc( 0x0000000000000000 ) > AT_stmt_list( 0x00000000 ) > AT_comp_dir( "/Users/mmp/foo" ) > AT_APPLE_optimized( 0x01 ) > AT_APPLE_flags( "-g" ) > > 0x00000039: TAG_s...

...gt; > >>>> wrote: > >>>> > Hi, > >>>> > > >>>> > I am looking for a way to get unmangled subprogram names from a > >>>> > DWARFContext. The name I want is available in the attribute > >>>> > `DW_AT_name` > >>>> > [1], but as far as I can tell this is only returned as a fallback in > >>>> > `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage > name > >>>> > is not > >>>> > available [2]. > >>>> &g...

...er at college.harvard.edu>wrote: > The use case for this is in Julia backtraces. We don't have a consistent > way to mangle the function names for linkage (we might at some point in the > future, but this is out of scope for now). Instead, we save whatever we > want displayed in AT_name, but there's no way to access that with the > public API (it works nicely in gdb/lldb though). > Alright, I see why it makes sense. We can pass this information through DILineInfoSpecifier. In fact, probably it makes sense to change the layout of this structure: there would be 3 types of...

On Mar 29, 2011, at 7:29 PM, Talin wrote: > I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: > > gdb stack crawl at point of internal error: > [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin

I've been trying to track down the problem with the DWARF info that is being emitted by my front end, which has been broken for about a month now. Here's what happens when I attempt to use gdb to debug one of my programs on OS X: gdb stack crawl at point of internal error: [ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300] [ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin

...help address pool issue too: even if a type uses an address, it would go in the CU but types referencing that type could still remain in a TU. So, barring anything else, I'm sort of inclined to just make all references to types in type units plain declarations (oh, also, DW_AT_declaration + DW_AT_name is smaller than DW_AT_declaration + DW_AT_signature (4 bytes instead of 8)). Simpler implementation, possible performance loss for the debugger (lacking the shortcut to find a type by signature instead of name lookup) and should tidy up a bunch of oddities as well as paving the way for improvements...