Displaying 20 results from an estimated 58 matches for "dw_tag_vari".
2015 Nov 18
3
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...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) DW_TAG_class_type
DW_AT_name (= "B")
(4) DW_TAG_variable
DW_AT_name (= "x")
DW_AT_type (= int)
(3) DW_TAG_variable
DW_AT_name (= "y")
DW_AT_type (=> B)
DW_AT_location
(3) DW_TAG_variable
DW_AT_name (= "z")
DW_AT_type (= A)
DW_AT_location
Case (b) - There is one abstract function, one inline function...
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...gt;
>
> (3) DW_TAG_imported_declaration
>
> DW_AT_import (=> N::D)
>
>
>
> (3) DW_TAG_typedef
>
> DW_AT_name (= "A")
>
> DW_AT_type (=> int)
>
>
>
> (3) DW_TAG_class_type
>
> DW_AT_name (= "B")
>
>
>
> (4) DW_TAG_variable
>
> DW_AT_name (= "x")
>
> DW_AT_type (= int)
>
>
>
> (3) DW_TAG_variable
>
> DW_AT_name (= "y")
>
> DW_AT_type (=> B)
>
> DW_AT_location
>
>
>
> (3) DW_TAG_variable
>
> DW_AT_name (= "z")
>
> DW_...
2011 Aug 04
2
[LLVMdev] metadata linking bug or by design
...bitcode files
from a.c and b.c, where the last element of !5 refers to the internal
variable x.
!llvm.dbg.sp = !{!1}
!5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
i32 1, i32* @x} ; [ DW_TAG_variable ]
However after linking the last element of !11 becomes null. I was
expecting that it would refer to the renamed x1.
!llvm.dbg.gv = !{!9, !11}
!9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
metadata !"x", metadata !"", metadata !3, i32 1, metadat...
2011 Aug 04
2
[LLVMdev] metadata linking bug or by design
...t of !5 refers to the internal
>> variable x.
>>
>> !llvm.dbg.sp = !{!1}
>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>
>> However after linking the last element of !11 becomes null. I was
>> expecting that it would refer to the renamed x1.
>>
>> !llvm.dbg.gv = !{!9, !11}
>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>> metadata !"...
2011 Aug 04
0
[LLVMdev] metadata linking bug or by design
..., where the last element of !5 refers to the internal
> variable x.
>
> !llvm.dbg.sp = !{!1}
> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
> i32 1, i32* @x} ; [ DW_TAG_variable ]
>
> However after linking the last element of !11 becomes null. I was
> expecting that it would refer to the renamed x1.
>
> !llvm.dbg.gv = !{!9, !11}
> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
> metadata !"x", metadata !"...
2018 Mar 23
2
Question about debug information for global variables
...y llvm-dwarfdump?
>>
>> This is what I see printed by llvm-dwarfdump using the command-line:
>> llvm-dwarfdump -verify-debug-info -debug-dump=all myobjectfile.o
>>
>>
>> The DW_AT_location values are different:
>>
>> With deref:
>> 0x00000032: DW_TAG_variable [2]
>> DW_AT_name [DW_FORM_strp] (
>> .debug_str[0x0000001d] = "var1")
>> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
>> DW_AT_external [DW_FORM_flag_present] (true)
>>...
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
...name
> .byte 1 # DW_AT_decl_file
> .byte 2 # DW_AT_decl_line
> .int 146 # DW_AT_type
> .byte 2 # DW_AT_location
> .byte 145
> .byte 20
> .byte 4 # Abbrev [4] 0x54:0xe DW_TAG_variable
> .int Linfo_string8 # DW_AT_name
> .byte 1 # DW_AT_decl_file
> .byte 4 # DW_AT_decl_line
> .int 127 # DW_AT_type
> .byte 2 # DW_AT_location
> .byte 145
> .byte 16
> .byte...
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
...;d0> DW_AT_location : 0x48 (location list)
<d4> DW_AT_name : (indirect string, offset: 0xc7): argv
<d8> DW_AT_decl_file : 1
<d9> DW_AT_decl_line : 16
<da> DW_AT_type : <0x5e>
<2><de>: Abbrev Number: 10 (DW_TAG_variable)
<df> DW_AT_const_value : 0
<e0> DW_AT_name : (indirect string, offset: 0xcc): i
<e4> DW_AT_decl_file : 1
<e5> DW_AT_decl_line : 18
<e6> DW_AT_type : <0x3f>
<2><ea>: Abbrev Number: 11 (DW_TAG_variab...
2018 Mar 23
0
Question about debug information for global variables
...gt;> This is what I see printed by llvm-dwarfdump using the command-line:
>>> llvm-dwarfdump -verify-debug-info -debug-dump=all myobjectfile.o
>>>
>>>
>>> The DW_AT_location values are different:
>>>
>>> With deref:
>>> 0x00000032: DW_TAG_variable [2]
>>> DW_AT_name [DW_FORM_strp] (
>>> .debug_str[0x0000001d] = "var1")
>>> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
>>> DW_AT_external [DW_FORM_flag_present] (true)
>&...
2011 Aug 04
0
[LLVMdev] metadata linking bug or by design
...ernal
>>> variable x.
>>>
>>> !llvm.dbg.sp = !{!1}
>>> !5 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x",
>>> metadata !"x", metadata !"", metadata !2, i32 1, metadata !6, i32 1,
>>> i32 1, i32* @x} ; [ DW_TAG_variable ]
>>>
>>> However after linking the last element of !11 becomes null. I was
>>> expecting that it would refer to the renamed x1.
>>>
>>> !llvm.dbg.gv = !{!9, !11}
>>> !9 = metadata !{i32 655412, i32 0, metadata !0, metadata !"x"...
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
2020 Apr 15
4
Seeking clarification and way forward on limited scope variables.
...all calls to “dbg.declare(…)” with “dbg.value(…, DW_OP_deref)”, and compiled with `-g -O0 -mllvm -fast-isel=false` (apparently FastISel doesn’t know what to do with frame-index dbg.values, but this is simple to fix). This seemed to work pretty well, and the DWARF looked legit:
```
0x0000005f: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -20)
DW_AT_name ("Local")
0x0000006d: DW_TAG_lexical_block
DW_AT_low_pc (0x0000000100000f4f)
DW_AT_high_pc (0x0000000100000f84)
0x0000007a: DW_TAG_variable...
2018 Mar 22
2
Question about debug information for global variables
...;> to its value.
>
> Can you share the final expression as printed by llvm-dwarfdump?
This is what I see printed by llvm-dwarfdump using the command-line:
llvm-dwarfdump -verify-debug-info -debug-dump=all myobjectfile.o
The DW_AT_location values are different:
With deref:
0x00000032: DW_TAG_variable [2]
DW_AT_name [DW_FORM_strp] (
.debug_str[0x0000001d] = "var1")
DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
DW_AT_external [DW_FORM_flag_present] (true)
DW_AT_location [DW_FORM_exprloc]...
2018 Mar 22
0
Question about debug information for global variables
...he final expression as printed by llvm-dwarfdump?
>
> This is what I see printed by llvm-dwarfdump using the command-line:
> llvm-dwarfdump -verify-debug-info -debug-dump=all myobjectfile.o
>
>
> The DW_AT_location values are different:
>
> With deref:
> 0x00000032: DW_TAG_variable [2]
> DW_AT_name [DW_FORM_strp] (
> .debug_str[0x0000001d] = "var1")
> DW_AT_type [DW_FORM_ref4] (cu + 0x0049 => {0x00000049})
> DW_AT_external [DW_FORM_flag_present] (true)
> DW_AT_location [D...
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
2020 Apr 15
2
Seeking clarification and way forward on limited scope variables.
...o when the variable is actually defined(or allocated) which is in
this case Line No. 7.
---------------------------------------------
0x0000006d: DW_TAG_lexical_block
DW_AT_low_pc (0x00000000002016d1)
DW_AT_high_pc (0x000000000020170b)
0x0000007a: DW_TAG_variable
DW_AT_location (DW_OP_fbreg -24)
DW_AT_name ("Local")
DW_AT_decl_file ("MainScope.c")
DW_AT_decl_line (7)
DW_AT_type (0x0000008a "int")
-------------...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
Hi Devs,
consider below testcase
$cat test.c
__thread int mtls=1;
void foo(){
mtls++;
}
it emits this debug info for mtls
0x0000002a: DW_TAG_variable
DW_AT_name ("mtls")
DW_AT_type (0x00000035 "int")
DW_AT_external (true)
DW_AT_decl_file ("test.c")
DW_AT_decl_line (1)
which does not contain DW_AT_Location.
Currently, aar...
2018 Nov 01
4
Fwd: RFC: Adding debug information to LLVM to support Fortran
...= distinct !DIGlobalVariable(scope: !20, name: "j", file: !3, type: !28)
!32 = !DIExpression(DW_OP_plus_uconst, 4)
!33 = !DIGlobalVariableExpression(var: !31, expr: !32)
The DWARF generated for this is as follows.
DW_TAG_common_block:
DW_AT_name: alpha
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: common alpha
DW_AT_type: array of 8 bytes
DW_AT_location: @alpha_+0
DW_TAG_variable:
DW_AT_name: i
DW_AT_type: integer*4
DW_AT_location: @alpha+0
DW_TAG_variable:
DW_AT_name: j
DW_AT_type: integer*4
DW_AT_location: @alpha+4
--
Eric
-------------- next part ----------...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
...ev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi Devs,
>>
>> consider below testcase
>> $cat test.c
>> __thread int mtls=1;
>> void foo(){
>> mtls++;
>> }
>>
>> it emits this debug info for mtls
>>
>> 0x0000002a: DW_TAG_variable
>> DW_AT_name ("mtls")
>> DW_AT_type (0x00000035 "int")
>> DW_AT_external (true)
>> DW_AT_decl_file ("test.c")
>> DW_AT_decl_line (1)
>>
&...
2012 Feb 11
0
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...ppy about that (e.g., ERROR: ctfconvert:
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&g...