search for: compile_unit

...ttp://lists.llvm.org/pipermail/llvm-dev/attachments/20090924/2b151f08/attachment.bin> -------------- next part -------------- File Name: sql_insert.cc [14447] File Name: [14 x i8] c"sql_insert.cc\00, LineNo: 1313, Inst: call void @llvm.dbg.stoppoint(i32 1313, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit134216 to { }*)) [14448] File Name: [14 x i8] c"sql_insert.cc\00, LineNo: 1316, Inst: call void @llvm.dbg.stoppoint(i32 1316, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit134216 to { }*)) [14449] File Name: [14 x i8] c"sql_insert.cc\...

..."main(tart.core.Array[tart.core.String])->int"(%"tart.core.Array[tart.core.String]"* %args) { entry: call void @llvm.dbg.func.start({ }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*)) call void @llvm.dbg.stoppoint(i32 6, i32 22, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) %testModuleReflection = call { } @testModuleReflection() ; <{ }> [#uses=0] call void @llvm.dbg.stoppoint(i32 7, i32 19, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) %testModuleMethods = call { } @testModuleMethods() ;...

...1, short %br_data_2, short %br_data_3, short %br_data_4, short %br_data_5, short %br_data_6, short %br_data_7) { entry: %dbg.1 = tail call { }* %llvm.dbg.func.start( %lldb.global* %d.test ) ; <{ }*> [#uses=1] %dbg.tmp.1 = tail call { }* %llvm.dbg.stoppoint( { }* %dbg.1, uint 10, uint 0, %lldb.compile_unit* %d.compile_unit ) ; <{ }*> [#uses=1] %dbg.tmp.3 = tail call { }* %llvm.dbg.stoppoint( { }* %dbg.tmp.1, uint 17, uint 0, %lldb.compile_unit* %d.compile_unit ) ; <{ }*> [#uses=1] %tmp.6 = add short %br_data_1, %br_data_0 ; <short> [#uses=1] %tmp.15 = add short %tmp.6, %br_data_2 ;...

..._attribute__((always_inline)) void f2() { f1(); } inl1.cpp: #include "inl.h" void c1() { f2(); } inl2.cpp: #include "inl.h" void c2() { f2(); } Compile to IR, llvm-link the result. The DWARF you get is basically the same as the DWARF you'd get without linking: DW_TAG_compile_unit DW_AT_name "inl1.cpp" DW_TAG_subprogram #0 DW_AT_name "f2" DW_TAG_subprogram DW_AT_name "c1" DW_TAG_inlined_subroutine DW_TAG_abstract_origin #0 "f2" DW_TAG_compile_unit DW_AT_name "inl2.cpp" DW_TAG_subprogram #1 DW_A...

...include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...include "inl.h" > void c1() { > f2(); > } > inl2.cpp: > #include "inl.h" > void c2() { > f2(); > } > > Compile to IR, llvm-link the result. The DWARF you get is basically the > same as the DWARF you'd get without linking: > > DW_TAG_compile_unit > DW_AT_name "inl1.cpp" > DW_TAG_subprogram #0 > DW_AT_name "f2" > DW_TAG_subprogram > DW_AT_name "c1" > DW_TAG_inlined_subroutine > DW_TAG_abstract_origin #0 "f2" > DW_TAG_compile_unit > DW_AT_name "i...

...gt; f2(); >> } >> inl2.cpp: >> #include "inl.h" >> void c2() { >> f2(); >> } >> >> Compile to IR, llvm-link the result. The DWARF you get is basically the >> same as the DWARF you'd get without linking: >> >> DW_TAG_compile_unit >> DW_AT_name "inl1.cpp" >> DW_TAG_subprogram #0 >> DW_AT_name "f2" >> DW_TAG_subprogram >> DW_AT_name "c1" >> DW_TAG_inlined_subroutine >> DW_TAG_abstract_origin #0 "f2" >> DW_TAG_compil...

...o { }*)) links to meta data for @llvm.dbg.variable9 which is: @llvm.dbg.variable9 = internal constant %llvm.dbg.variable.type { i32 459008, { }* bitcast (%llvm.dbg.subprogram.type* @llvm.dbg.subprogram to { }*), i8* getelementptr inbounds ([2 x i8]* @.str8, i32 0, i32 0), { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*), i32 13, { }* bitcast (%llvm.dbg.basictype.type* @llvm.dbg.basictype to { }*) }, section "llvm.metadata" ; <%llvm.dbg.variable.type*> [#uses=1] now what I'm interested is the line number "i32 13" shown in the metadata of @llvm.dbg...

...istence of foo.xx, the original source file. I have compiled a small helloworld.c program, and compared the debug info in helloworld and foo, using 'readelf --debug-dump'. I have noticed that in helloworld, the .debug_aranges section has 2 address ranges, - one pointing to a DW_TAG_compile_unit referencing the /sysdeps/i386/elf/start.S file - the other pointing to a DW_TAG_compile_unit with the helloworld,c file. However, in the foo program, the .debug_aranges section has only 1 address range, pointing to a DW_TAG_compile_unit referencing the /sysdeps/i386/elf/start.S file. The se...

...gating some code patterns with LLVM IR, I need to know where this IR code come from (the line number in a source file name). An existing way is using -g option to compile my software, then I can get something as below: call void @llvm.dbg.stoppoint(i32 9, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit17 to { }*)) I know that the first argument is line number, and the third argument, the compile unit llvm.dbg.compile_unit17, is mapped to a source file. I can get the first line number very easily by "CallSite::arg_iterator" (and represent the firs...

...l type; and in some simple cases it is able to pretty-print array references as well: For example consider this snippet: call void @llvm.dbg.declare({ }* %i2, { }* bitcast (%llvm.dbg.variable.type* @llvm.dbg.variable13 to { }*)) call void @llvm.dbg.stoppoint(i32 11, i32 0, { }* bitcast (%llvm.dbg.compile_unit.type* @llvm.dbg.compile_unit to { }*)) %0 = load %struct.test** %x_addr, align 8 ; <%struct.test*> [#uses=1] %1 = getelementptr %struct.test* %0, i32 0, i32 0 ; <[10 x i8]*> [#uses=1] %2 = getelementptr [10 x i8]* %1, i32 0, i64 10 ; <i8*> [#uses=1] %2 is pre...

...gt; f2(); >> } >> inl2.cpp: >> #include "inl.h" >> void c2() { >> f2(); >> } >> >> Compile to IR, llvm-link the result. The DWARF you get is basically the >> same as the DWARF you'd get without linking: >> >> DW_TAG_compile_unit >> DW_AT_name "inl1.cpp" >> DW_TAG_subprogram #0 >> DW_AT_name "f2" >> DW_TAG_subprogram >> DW_AT_name "c1" >> DW_TAG_inlined_subroutine >> DW_TAG_abstract_origin #0 "f2" >> DW_TAG_compil...

...in the code, but how to generate them is still a little fuzzy, mainly because llvm_expand is a little complicated. (I blame C++). - I can see how I would generate the calls to the llvm.dbg.stoppoint intrinsic, but it isn't as clear how I'd generate the global anchors, string constants, or compile_unit constants. - What types are the ones declared as {}* ? It isn't void, but I don't see a type declaration for it in llvm* in the cfe. - I understand how the def-use links work to chain the debug statements together, but on a strictly time-saving basis, it seems like it'd still be valid...

On Oct 10, 2008, at 1:43 PM, John Criswell wrote: > Dear All, > > Are there a set of libraries for easily manipulating the LLVM debug > information? For example, given an Instruction *, is there an > interface > that will find the nearest llvm.dbg.stoppoint(), or given an alloca, > is > there an interface for getting its source level information by tracing > it to

Dear All, Are there a set of libraries for easily manipulating the LLVM debug information? For example, given an Instruction *, is there an interface that will find the nearest llvm.dbg.stoppoint(), or given an alloca, is there an interface for getting its source level information by tracing it to a llvm.dbg.declare()? As far as I know, no such utility interfaces exist. While I can role my

...ar to be in compile unit "file1", 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&qu...

..."file1", 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" ... > ......

I'm trying to generate the declarations for function intrinsics, and I must be misunderstanding how to create new functions - I saw that a function with no basic blocks is treated as a declaration, so I tried to just create one and add it to the globals list: llvm_type *structTy, *ptrToStructTy; structTy = llvm_type_create_struct(0, 0); structTy =

However, I do have: !924 = metadata !{i32 786484, i32 0, null, metadata !"r", metadata !"r", metadata !"", metadata !841, i32 19, metadata !56, i32 0, i32 1, i32* @r} ; [ DW_TAG_variable ] [r] [line 19] [def] with on which `!0` is indirectly dependent and there is `!llvm.dbg.cu = !{!0}` . On Wed, Feb 27, 2013 at 11:35 AM, Alexandru Ionut Diaconescu <

17.09.2019 3:12, David Blaikie пишет: > > > On Wed, Sep 11, 2019 at 3:32 PM Alexey Lapshin via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Debuginfo and linker folks, we (AccessSoftek) would like to > suggest a proposal for removing obsolete debug info. If you find > it useful we will be happy to work on