Displaying 20 results from an estimated 160 matches for "dw_at_nam".
Did you mean:
dw_at_name
2016 Dec 15
6
distinct DISubprograms hindering sharing inlined subprogram descriptions
...lways_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_AT_name "...
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
...nto Abbrev. Section
> .byte 4 # Address Size (in bytes)
> .byte 1 # Abbrev [1] 0xb:0x8d DW_TAG_compile_unit
> .int Linfo_string0 # DW_AT_producer
> .short 12 # DW_AT_language
> .int Linfo_string1 # DW_AT_name
> .int 0 # DW_AT_low_pc
> .int Lsection_line # DW_AT_stmt_list
> .int Linfo_string2 # DW_AT_comp_dir
> .byte 2 # Abbrev [2] 0x22:0x5d DW_TAG_subprogram
> .int Linfo_string3 # DW_AT_name
> .byte 1...
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
....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"
>...
2016 Dec 15
1
distinct DISubprograms hindering sharing inlined subprogram descriptions
...t; 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
> &g...
2012 Sep 21
1
[LLVMdev] relocation visitor
...m-dwarfdump isn't very useful on ELF .o files because it
doesn't apply relocations.
nlewycky at ducttape:~$ llvm-dwarfdump helloworld.o | grep debug_str\\[
0x0000000c: DW_AT_producer [DW_FORM_strp] ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000012: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] = "clang
version 3.2 (trunk 163034)")
0x00000022: DW_AT_comp_dir [DW_FORM_strp] ( .debug_str[0x00000000] =
"clang version 3.2 (trunk 163034)")
0x00000027: DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000000] =
"clang ve...
2014 May 07
2
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
Hi,
I am looking for a way to get unmangled subprogram names from a
DWARFContext. The name I want is available in the attribute `DW_AT_name`
[1], but as far as I can tell this is only returned as a fallback in
`DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name is
not available [2].
If this is not currently possible, is there any interest in adding such
access to the public DebugInfo API? Perhaps with an additional...
2014 Feb 18
1
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
All of this information is contained in the DWARF debug info that you must generate. Are you generating DWARF? If not, you will need to. If so, please attach an example program that contains DWARF and specify which function you are having trouble getting variable information for.
Greg Clayton
On Feb 18, 2014, at 12:44 AM, 杨勇勇 <triple.yang at gmail.com> wrote:
> Hi, all
>
> I
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...quot;
> 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"
>...
2014 May 07
2
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
...echristo at gmail.com>wrote:
> On Tue, May 6, 2014 at 8:09 PM, Isaiah Norton <isaiah.norton at gmail.com>
> wrote:
> > Hi,
> >
> > I am looking for a way to get unmangled subprogram names from a
> > DWARFContext. The name I want is available in the attribute `DW_AT_name`
> > [1], but as far as I can tell this is only returned as a fallback in
> > `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name is
> not
> > available [2].
> >
> > If this is not currently possible, is there any interest in adding such
> >...
2015 Nov 18
3
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...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_type (=> int)
(3...
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
...ain":
<1><a7>: Abbrev Number: 7 (DW_TAG_subprogram)
<a8> DW_AT_low_pc : 0x400880
<b0> DW_AT_high_pc : 0xc9
<b4> Unknown AT value: 3fe7: 1
<b4> DW_AT_frame_base : 1 byte block: 57 (DW_OP_reg7 (rsp))
<b6> DW_AT_name : (indirect string, offset: 0xaf): main
<ba> DW_AT_decl_file : 1
<bb> DW_AT_decl_line : 16
<bc> DW_AT_prototyped : 1
<bc> DW_AT_type : <0x3f>
<c0> DW_AT_external : 1
<c0> Unknown AT value: 3fe1: 1...
2014 Feb 18
4
[LLVMdev] How is variable info retrieved in debugging for executables generated by llvm backend?
Hi, all
I ported llvm backend and lldb recently. Both tools can basically work.
lldb is able to debug programs in asm style and frame unwinding is OK.
But "frame variable XX" does not work because lldb is not able to determine
the address of
XX from debug info.
Can someone give any clue?
Thanks in advance.
--
杨勇勇 (Yang Yong-Yong)
-------------- next part --------------
An HTML
2016 Dec 15
2
distinct DISubprograms hindering sharing inlined subprogram descriptions
...quot;
> 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"
>...
2014 May 07
2
[LLVMdev] DWARF unmangled subprog name (DW_AT_name)
...2014 at 8:09 PM, Isaiah Norton <isaiah.norton at gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I am looking for a way to get unmangled subprogram names from a
>>> > DWARFContext. The name I want is available in the attribute
>>> `DW_AT_name`
>>> > [1], but as far as I can tell this is only returned as a fallback in
>>> > `DWARFDebugInfoEntryMinimal::getSubroutineName` when the linkage name
>>> is not
>>> > available [2].
>>> >
>>> > If this is not currently possible...
2012 Feb 11
0
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...onvert:
die 141: base type without name). Is it intended behavior?
Simple testcase:
int
main(void)
{
int i[2];
return 0;
}
dwarfdump output:
clang version 3.0 (tags/RELEASE_30/final):
[...]
LOCAL_SYMBOLS:
[...]
<3>< 120> DW_TAG_variable
DW_AT_name i
DW_AT_decl_file 1 /home/yuri/test.c
DW_AT_decl_line 4
DW_AT_type <144>
DW_AT_location DW_OP_fbreg 0
<1>< 134> DW_TAG_base_type...
2012 Feb 11
2
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...onvert:
die 141: base type without name). Is it intended behavior?
Simple testcase:
int
main(void)
{
int i[2];
return 0;
}
dwarfdump output:
clang version 3.0 (tags/RELEASE_30/final):
[...]
LOCAL_SYMBOLS:
[...]
<3>< 120> DW_TAG_variable
DW_AT_name i
DW_AT_decl_file 1 /home/yuri/test.c
DW_AT_decl_line 4
DW_AT_type <144>
DW_AT_location DW_OP_fbreg 0
<1>< 134> DW_TAG_base_type...
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
...# Address Size (in bytes)
.byte 1 # Abbrev [1] 0xb:0x130 DW_TAG_compile_unit
.ascii "clang version 3.0 (tags/RELEASE_30/final)" # DW_AT_producer
.byte 0
.short 12 # DW_AT_language
.ascii "a.c" # DW_AT_name
.byte 0
.long 0 # DW_AT_entry_pc
.long .Lsection_line # DW_AT_stmt_list
.ascii "/home/marco/clang_issue" # DW_AT_comp_dir
.byte 0
.byte 2 # Abbrev [2] 0x5c:0x7 DW_TAG_base_type
.ascii "int" # DW_AT_n...
2016 Dec 23
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
....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"
>...
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...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_...
2016 Dec 15
0
distinct DISubprograms hindering sharing inlined subprogram descriptions
...gt;> 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_...