search for: at_loc

...nding 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 correct, based on an eyeballing of the assembly output, so there's nothing obviously wrong there, either. > > I'd be delighted to hear any suggestions or pointers! > > Thanks, > -...

...AT_decl_file( "/llvm_cmake/test.cc <http://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 &lt...

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

...uot;/llvm_cmake/test.cc <http://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_c...

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

...name( "bar" ) AT_decl_file( "/llvm_cmake/test.cc<http://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<http://test.cc/>&...

...nding 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 correct, based on an eyeballing of the assembly output, so there's nothing obviously wrong there, either. I'd be delighted to hear any suggestions or pointers! Thanks, -matt

...DW_TAG_lexical_block ] !16 = metadata !{i32 2, i32 2, metadata !14, null} !17 = metadata !{i32 3, i32 3, metadata !14, null} !18 = metadata !{i32 4, i32 4, metadata !14, null} --- And this is what dwarfdump on the compiled object file shows. The TAG_variable entry for 'bar' is missing its AT_location. --- ---------------------------------------------------------------------- File: foo.o (x86_64) ---------------------------------------------------------------------- .debug_info contents: 0x00000000: Compile Unit: length = 0x000000a9 version = 0x0002 abbr_offset = 0x00000000 addr_size...

...metadata !{i32 2, i32 2, metadata !14, null} > !17 = metadata !{i32 3, i32 3, metadata !14, null} > !18 = metadata !{i32 4, i32 4, metadata !14, null} > --- > > And this is what dwarfdump on the compiled object file shows. The > TAG_variable entry for 'bar' is missing its AT_location. > > --- > ---------------------------------------------------------------------- >  File: foo.o (x86_64) > ---------------------------------------------------------------------- > .debug_info contents: > > 0x00000000: Compile Unit: length = 0x000000a9  version = 0x0002...