search for: tag_subprogram

...le1", the variable a appears to be in compile unit "file2" (and there are no basic types in file2, so int is not defined), and fn2 appears to be in compile unit "file3". My dwarf records are therefore incorrect, appearing something like TAG_compile_unit "file1" TAG_subprogram "fn1" ... ... TAG_base_type "int" ... TAG_compile_init "file2" TAG_variable "a" ... TAG_compile_unit "file3" TAG_subprogram "fn2" ... ... When, in fact, these compile units "file2" and "file3" are bogus...

...us ) > 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_frame_base( rbp ) > AT_MIPS_linkage_name( "_Z3bari" ) > AT_name( "bar" ) > AT_decl_file...

...etadata !5} !5 = metadata !{i32 720942, i32 0, metadata !6, metadata !"foo", metadata !"foo", metadata !"\01_main", metadata !7, i32 1, metadata !8, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @"\01_main", null, null, metadata !11} ; [ DW_TAG_subprogram ] !6 = metadata !{i32 720953, null, metadata !"__main__", metadata !7, i32 1} ; [ DW_TAG_namespace ] !7 = metadata !{i32 720937, metadata !"foo.clay", metadata !"", null} ; [ DW_TAG_file_type ] !8 = metadata !{i32 720917, i32 0, metadata !"", i32 0, i32 0, i6...

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

...ars to be in compile unit "file2" (and there are > no basic types in file2, so int is not defined), and fn2 appears to be in > compile unit "file3". My dwarf records are therefore incorrect, appearing > something like > > TAG_compile_unit "file1" > TAG_subprogram "fn1" ... > ... > TAG_base_type "int" ... > > TAG_compile_init "file2" > TAG_variable "a" ... > > TAG_compile_unit "file3" > TAG_subprogram "fn2" ... > ... > > When, in fact, these compile...

...T_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_frame_base( rbp ) >> AT_MIPS_linkage_name( "_Z3bari" ) >> AT_name( "bar" ) >>...

...= metadata !{i32 720942, i32 0, metadata !6, metadata !"foo", metadata > !"foo", metadata !"\01_main", metadata !7, i32 1, metadata !8, i1 false, i1 > true, i32 0, i32 0, i32 0, i32 0, i1 false, i32 ()* @"\01_main", null, null, > metadata !11} ; [ DW_TAG_subprogram ] > !6 = metadata !{i32 720953, null, metadata !"__main__", metadata !7, i32 1} > ; [ DW_TAG_namespace ] > !7 = metadata !{i32 720937, metadata !"foo.clay", metadata !"", null} ; [ > DW_TAG_file_type ] > !8 = metadata !{i32 720917, i32 0, metadata !&quot...

...0000883 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/...

...; dwarfdump output what is 0x00000883 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/r...

...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_frame_base( rbp ) AT_MIPS_linkage_name( "_Z3bari" ) AT_name( "bar" ) AT_decl_file( "/llvm_cmake/test.cc&lt...

...), I'd like to >> see "Value returns is $1 = 5"). I'm generating debug metadata nodes >> directly instead of using DIBuilder since it doesn't seem to >> encapsulate situations like this. > > So, I assume you figured out how to create metadata nodes for TAG_subprogram and corresponding TAG_subroutine_type. If yes, then the zero'th element of array of types you supply (subroutine_type is encoded as composite type, see http://llvm.org/docs/SourceLevelDebugging.html#format_composite_type) is return type. > > Let's say you have > > 1 &g...

...hen exiting from foo2(), I'd like to > see "Value returns is $1 = 5"). I'm generating debug metadata nodes > directly instead of using DIBuilder since it doesn't seem to > encapsulate situations like this. So, I assume you figured out how to create metadata nodes for TAG_subprogram and corresponding TAG_subroutine_type. If yes, then the zero'th element of array of types you supply (subroutine_type is encoded as composite type, see http://llvm.org/docs/SourceLevelDebugging.html#format_composite_type) is return type. Let's say you have 1 2 int foo() {...

The Rust compiler defines all functions as returning void, with the first parameter being an outparam of the declared return type, ie. fn foo2() -> int { ret 5; } becomes define void @_ZN4foo217_5cb557d30658848cE(i64*, { i64, { %tydesc*, i1, {} } }*) uwtable { store i64 5, i64* %0 ret void } I'm working on generating debug information for Rust, and I'm currently stumped on how

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/tru...

...om foo2(), I'd like to > see "Value returns is $1 = 5"). I'm generating debug metadata nodes > directly instead of using DIBuilder since it doesn't seem to > encapsulate situations like this. > > > So, I assume you figured out how to create metadata nodes for TAG_subprogram > and corresponding TAG_subroutine_type. If yes, then the zero'th element of > array of types you supply (subroutine_type is encoded as composite type, see > http://llvm.org/docs/SourceLevelDebugging.html#format_composite_type) is > return type. > > Let's say you have >...

...llvm.dbg.lv.foo___ = !{!4} !0 = metadata !{i32 589870, i32 0, metadata !1, metadata !"foo", metadata !"foo", metadata !"foo___", metadata !1, i32 4, metadata !3, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 true, i32 (<4 x i32>)* @foo___, null, null} ; [ DW_TAG_subprogram ] !1 = metadata !{i32 589865, metadata !"a.c", metadata !"/Users/mmp/foo/", metadata !2} ; [ DW_TAG_file_type ] !2 = metadata !{i32 589841, i32 0, i32 12, metadata !"a.c", metadata !"/Users/mmp/foo", metadata !"foo", i1 true, i1 true, metadata !&quo...

...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 ) > AT_high_pc( 0x0000000112f5f8bb ) > AT_frame_base( rbp ) > AT_MIPS_linkage_name( "julia_parseint_nocheck;18749" ) > AT_name( "parseint_nocheck&...

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

...v.foo___ = !{!4} > > !0 = metadata !{i32 589870, i32 0, metadata !1, metadata !"foo", metadata !"foo", metadata !"foo___", metadata !1, i32 4, metadata !3, i1 false, i1 true, i32 0, i32 0, i32 0, i32 0, i1 true, i32 (<4 x i32>)* @foo___, null, null} ; [ DW_TAG_subprogram ] > !1 = metadata !{i32 589865, metadata !"a.c", metadata !"/Users/mmp/foo/", metadata !2} ; [ DW_TAG_file_type ] > !2 = metadata !{i32 589841, i32 0, i32 12, metadata !"a.c", metadata !"/Users/mmp/foo", metadata !"foo", i1 true, i1 true, meta...

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