search for: at_frame_base

...ough "foo", the value "0" is always printed for "r". > > One other piece of possibly relevant information is that if I run "dwarfdump" on both of the corresponding object files, the output is almost entirely the same, though in the working case, it had AT_frame_base( rsp ), while the broken case had AT_frame_base( rbp ). Some of the PC extents are different, but in ways that look reasonable. For the location of "r" in the working case, it has AT_location( fbreg -4 ), with AT_location( fbreg +28 ) in the broken case. These locations both seem correc...

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

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

...quot; ) >> 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 ) >> A...

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

...epping through "foo", the value "0" is always printed for "r". One other piece of possibly relevant information is that if I run "dwarfdump" on both of the corresponding object files, the output is almost entirely the same, though in the working case, it had AT_frame_base( rsp ), while the broken case had AT_frame_base( rbp ). Some of the PC extents are different, but in ways that look reasonable. For the location of "r" in the working case, it has AT_location( fbreg -4 ), with AT_location( fbreg +28 ) in the broken case. These locations both seem correc...

...AT_encoding( DW_ATE_signed ) AT_byte_size( 0x04 ) 0x00000065: TAG_subprogram [5] * AT_specification( {0x00000048} ( "_main" ) ) AT_low_pc( 0x0000000000000020 ) AT_high_pc( 0x0000000000000051 ) AT_frame_base( rbp ) 0x0000007c: TAG_lexical_block [6] * AT_low_pc( 0x0000000000000028 ) AT_high_pc( 0x000000000000004c ) 0x0000008d: TAG_lexical_block [6] * AT_low_pc( 0x0000000000000028 ) AT_high_p...

...AT_APPLE_optimized( 0x01 ) > AT_low_pc( 0x0000000112f5f1c0 ) > AT_high_pc( 0x000006fb ) > > 0x0000002b: TAG_subprogram [2] > AT_low_pc( 0x0000000112f5f1c0 ) > AT_high_pc( 0x0000000112f5f8bb ) > AT_frame_base( rbp ) > AT_MIPS_linkage_name( "julia_parseint_nocheck;18749" ) > AT_name( "parseint_nocheck" ) > AT_external( 0x01 ) > AT_accessibility( DW_ACCESS_private ) > > 0x00000048: NULL > &gt...

...) >                  AT_byte_size( 0x04 ) > > 0x00000065:     TAG_subprogram [5] * >                  AT_specification( {0x00000048} ( "_main" ) ) >                  AT_low_pc( 0x0000000000000020 ) >                  AT_high_pc( 0x0000000000000051 ) >                  AT_frame_base( rbp ) > > 0x0000007c:         TAG_lexical_block [6] * >                      AT_low_pc( 0x0000000000000028 ) >                      AT_high_pc( 0x000000000000004c ) > > 0x0000008d:             TAG_lexical_block [6] * >                          AT_low_pc( 0x0000000000000028 ) &...

...eter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) > 0x000000d6: AT_external( 0x01 ) > 0x000000d7: AT_low_pc( 0x0000f780 ) > 0x000000db: AT_high_pc( 0x0000f7b1 ) > 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) > > 0x000000e1: NULL > > 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 > abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) > > 0x000000ed: TAG_compile_unit [1] * > 0x000000ee: AT_producer( .debug_str[0x000...

...unk/lib/std/tart/reflect/Parameter.tart" ) ) 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) 0x000000d6: AT_external( 0x01 ) 0x000000d7: AT_low_pc( 0x0000f780 ) 0x000000db: AT_high_pc( 0x0000f7b1 ) 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) 0x000000e1: NULL 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) 0x000000ed: TAG_compile_unit [1] * 0x000000ee: AT_producer( .debug_str[0x00000001] = "0.1 tartc" ) 0x00...

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

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

...eter.tart" ) ) > 0x000000d1: AT_decl_line( 0x0d ( 13 ) ) > 0x000000d2: AT_type( cu + 0x00000066 => {0x00000103} ( ) ) > 0x000000d6: AT_external( 0x01 ) > 0x000000d7: AT_low_pc( 0x0000f780 ) > 0x000000db: AT_high_pc( 0x0000f7b1 ) > 0x000000df: AT_frame_base( <0x1> 55 ( reg5 ) ) > > 0x000000e1: NULL > > 0x000000e2: Compile Unit: length = 0x00000071 version = 0x0002 abbr_offset = 0x00000000 addr_size = 0x04 (next CU at 0x00000157) > > 0x000000ed: TAG_compile_unit [1] * > 0x000000ee: AT_producer( .debug_str[0x00000...

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