search for: at_stmt_list

...ize = 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(...

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

...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 ) >>...

...bbr_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_f...

Anton Korobeynikov wrote: > 2. It can be, that debug information emitted is not correct. This is > known open problem. > The attached patch fixes the problem with the line information. For the "AT_stmt_list" attribute of the compilation unit entry, DWARF-2 specification says: > A DW_AT_stmt_list attribute whose value is a reference to line number > information for > this compilation unit. > This information is placed in a separate object file section from the > debugging inform...

Hello, Argiris > Any ideas? 1. Make sure, that you don't mix dwarf and stabs debug information. AFAIR, this can really mess the things 2. It can be, that debug information emitted is not correct. This is known open problem. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...= 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] AT_name( "foo" ) AT_MIPS_linkage_name( "foo___" )...

...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/Code/others/clay/foo.clay" ) AT_decl_line( 1 ) 0x00000048: TAG_sub...

...5 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] > AT_low_pc( 0x0000000112f5f1c0...

...d) > > 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/Code/others/clay/foo.clay" ) >                  AT_decl_line...

...ed: TAG_compile_unit [1] * > 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) > 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) > 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) > 0x000000f8: AT_entry_pc( 0x00004360 ) > 0x000000fc: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) > 0x00000100: AT_comp_dir( .debug_str[0x00000205] = > "/Users/talin/Projects/tart/trunk/lib/std/tart/core" ) > 0x00000104: AT_APPLE_major_runtime_vers( 0x01 ) > > In particular note that the DIE starting at 0x0c7, which is a > TAG_subprogra...

...at 0x00000157) 0x000000ed: TAG_compile_unit [1] * 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) 0x000000f8: AT_entry_pc( 0x00004360 ) 0x000000fc: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) 0x00000100: AT_comp_dir( .debug_str[0x00000205] = "/Users/talin/Projects/tart/trunk/lib/std/tart/core" ) 0x00000104: AT_APPLE_major_runtime_vers( 0x01 ) In particular note that the DIE starting at 0x0c7, which is a TAG_subprogram, has a return type (AT_type...

...n Jun 16, 2008, at 11:32 PM, Argiris Kirtzidis wrote: > Anton Korobeynikov wrote: >> 2. It can be, that debug information emitted is not correct. This is >> known open problem. >> > > The attached patch fixes the problem with the line information. > > For the "AT_stmt_list" attribute of the compilation unit entry, > DWARF-2 specification says: > >> A DW_AT_stmt_list attribute whose value is a reference to line >> number information for >> this compilation unit. >> This information is placed in a separate object file section from...

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

...0000 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] > AT_name( "foo" ) > AT_MIPS_linkage...

...ed: TAG_compile_unit [1] * > 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) > 0x000000f2: AT_language( 0x0002 ( DW_LANG_C ) ) > 0x000000f4: AT_name( .debug_str[0x000001fa] = "range.tart" ) > 0x000000f8: AT_entry_pc( 0x00004360 ) > 0x000000fc: AT_stmt_list( 0x00000000 ( 0x00000000 ) ) > 0x00000100: AT_comp_dir( .debug_str[0x00000205] = "/Users/talin/Projects/tart/trunk/lib/std/tart/core" ) > 0x00000104: AT_APPLE_major_runtime_vers( 0x01 ) > > In particular note that the DIE starting at 0x0c7, which is a TAG_subprogram, has a...

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