Displaying 20 results from an estimated 190 matches for "dw_tag_subprogram".
2016 Dec 15
6
distinct DISubprograms hindering sharing inlined subprogram descriptions
...}
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_AT_name "f2"
DW_TAG_subprogram
DW_AT_na...
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...> }
> 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_AT_name &q...
2016 Dec 15
1
distinct DISubprograms hindering sharing inlined subprogram descriptions
...quot;
> > 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_...
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...; }
> 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_AT_name &q...
2016 Dec 15
2
distinct DISubprograms hindering sharing inlined subprogram descriptions
...; }
> 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_AT_name &q...
2016 Dec 23
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...> }
> 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_AT_name &q...
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...nl.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_subp...
2016 Dec 23
2
distinct DISubprograms hindering sharing inlined subprogram descriptions
...; }
> 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_AT_name &q...
2016 May 08
2
Debug info scope of explicit casting type does not seem correct
That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*).
This is the code that creates DW_TAG_subprogram:
DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) {
...
// DW_TAG_inlined_subroutine may refer to this DIE.
DIE &SPDie = createAndAddDIE(dwarf::DW_TAG_subprogram, *ContextDIE, SP);
// Stop here and fill this in later, depending on whether or not this
//...
2016 May 07
2
Debug info scope of explicit casting type does not seem correct
Hi David,
OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope.
But how about that we are emitting a subprogram entry that has no attributes?
0x0000002b: DW_TAG_subprogram [3] *
0x0000002c: DW_TAG_typedef [4]
DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040})
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000060] = "T")
DW_AT_decl_file [DW_FORM_data...
2015 Nov 18
3
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...s case (a)
}
int bar() {
return foo();
}
Proposed representation in dwarf
Case (a) - There is only one concrete function with one lexical block (DW_TAG_lexical_block) entry. Each entity will have a dwarf entry placed under the lexical block scope the same as appear in the source.
(1) DW_TAG_subprogram (concrete)
DW_AT_name (= "foo")
DW_AT_low_pc
DW_AT_low_high
(2) LexicalBlock
DW_AT_low_pc
DW_AT_low_high
(3) DW_TAG_imported_module
DW_AT_import (=> N)
(3) DW_TAG_imported_declaration
DW_AT_import (=> N::D)
(3) DW_TAG_typedef
DW_AT_name (= "A")
DW_AT_...
2016 Dec 24
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...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&...
2016 Dec 15
2
distinct DISubprograms hindering sharing inlined subprogram descriptions
...}
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_AT_name "f2"
DW_TAG_subprogram
DW_AT_na...
2016 Dec 16
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...; }
> 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_AT_name &q...
2016 Dec 16
2
distinct DISubprograms hindering sharing inlined subprogram descriptions
...; }
> 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_AT_name &q...
2017 Apr 04
2
GDB doesn't work with IR-originated debug info
...output of the
dll gave the following:
0x00000296: DW_TAG_base_type [10]
DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] =
"void")
DW_AT_encoding [DW_FORM_data1] (0x00)
DW_AT_byte_size [DW_FORM_data1] (0x00)
....
0x00000cf8: DW_TAG_subprogram [16] *
DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30)
DW_AT_high_pc [DW_FORM_data4] (0x000002b4)
DW_AT_frame_base [DW_FORM_exprloc] (<0x1> 54 )
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00001616] =
"FB_FPUMP at...
2016 Dec 16
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...nl.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_subp...
2016 Apr 30
2
Debug info scope of explicit casting type does not seem correct
...ointing to a type under subprogram entry?!
This is the root cause of https://llvm.org/bugs/show_bug.cgi?id=27579
0x0000000b: DW_TAG_compile_unit [1] *
0x00000026: DW_TAG_pointer_type [2]
DW_AT_type [DW_FORM_ref4] (cu + 0x002c => {0x0000002c})
0x0000002b: DW_TAG_subprogram [3] *
0x0000002c: DW_TAG_typedef [4]
DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040})
DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000060] = "T")
DW_AT_decl_file [DW_FORM_data...
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...gt;
>
> *Proposed representation in dwarf*
>
> Case (a) - There is only one concrete function with one lexical block
> (DW_TAG_lexical_block) entry. Each entity will have a dwarf entry placed
> under the lexical block scope the same as appear in the source.
>
>
>
> (1) DW_TAG_subprogram (concrete)
>
> DW_AT_name (= "foo")
>
> DW_AT_low_pc
>
> DW_AT_low_high
>
>
>
> (2) LexicalBlock
>
> DW_AT_low_pc
>
> DW_AT_low_high
>
>
>
> (3) DW_TAG_imported_module
>
> DW_AT_import (=> N)
>
>
>
> (3) DW_TAG_imp...
2012 Feb 24
1
[LLVMdev] DW_AT_inline not present in assembly for an inlined inline function
...ne int t()
{
}
int q()
{
t();
}
The testcase fails because, DW_AT_inline is not present in assembly output.
Could anyone let me know why DW_AT_inline is not emitted with Clang
compiled assembly output?
I am aware that Clang uses C99 mode by default.
In case of GCC,
.uleb128 0x2 @ (DIE (0x25) DW_TAG_subprogram)
.byte 0x1 @ DW_AT_external
.ascii "t\0" @ DW_AT_name
.byte 0x1 @ DW_AT_decl_file (test.h)
.byte 0x1 @ DW_AT_decl_line
.4byte 0x30 @ DW_AT_type
.byte 0x3 @ DW_AT_inline
In case of Clang,
.byte 4...