Displaying 20 results from an estimated 75 matches for "dw_at_location".
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
...# Abbrev [3] 0x38:0xe
> DW_TAG_formal_parameter
> .int Linfo_string5 # DW_AT_name
> .byte 1 # DW_AT_decl_file
> .byte 2 # DW_AT_decl_line
> .int 127 # DW_AT_type
> .byte 2 # DW_AT_location
> .byte 145
> .byte 24
> .byte 3 # Abbrev [3] 0x46:0xe
> DW_TAG_formal_parameter
> .int Linfo_string6 # DW_AT_name
> .byte 1 # DW_AT_decl_file
> .byte 2 # DW_AT_decl_line
> .int 146...
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
...: 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
<2><c0>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<c1> DW_AT_location : 0x23 (location list)
<c5> DW_AT_name : (indirect string, offset: 0xc2): argc
<c9> DW_AT_decl_file : 1
<ca> DW_AT_decl_line : 16
<cb> DW_AT_type : <0x3f>
<2><cf>: Abbrev Number: 8 (DW_TAG_formal_parameter)...
2015 Nov 18
3
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...port (=> 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 (DW_TAG_inlined_subroutine) and one concrete function, each has one lexical block entry.
Each entity will have a dwarf entry placed under the...
2020 Jan 21
4
aarch64 does not emit DW_AT_Location
Hi Devs,
debug info emitted by llvm does not contain DW_AT_Location for Formal
parameter
if it is an aggregate like below case
1) aggregate contain more than 4 homogeneous and size more than 128 bits
i.e.
typedef struct{
int a,b,c,d,e;
}mystruct;
void foo(mystruct ms){
}
2) aggregate contain hetrogeneous type and size more than 128 bits.
i.e.
typedef struct{
int a...
2018 Mar 23
2
Question about debug information for global variables
...t; 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})
>&...
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
2018 Mar 23
0
Question about debug information for global variables
...;
>>>> 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 =...
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
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
...TAG_variable
.ascii "something" # DW_AT_name
.byte 0
.long 92 # DW_AT_type
.byte 1 # DW_AT_external
.byte 1 # DW_AT_decl_file
.byte 6 # DW_AT_decl_line
.byte 5 # DW_AT_location
.byte 3
.long something
.byte 3 # Abbrev [3] 0x7b:0x1d DW_TAG_variable
.ascii "something_else" # DW_AT_name
.byte 0
.long 92 # DW_AT_type
.byte 1 # DW_AT_external
.byte 1 # DW_AT_decl_fil...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
...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, aarch64 does not emit DW_AT_Location for TLS variables.
I could see at this line, it says some restriction in aarch64 elf abi.
https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64TargetObjectFile.cpp#L24
I would like to know community thoughts on this and is ther...
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...>
> (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
> (DW_TAG_inlined_subroutine) and one concrete function, each has one
&...
2018 Mar 22
2
Question about debug information for global variables
...offset is always added to the address of BaseAddress and not
>> 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]...
2018 Mar 22
0
Question about debug information for global variables
...seAddress and not
>>> 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_ex...
2019 Dec 10
2
aarch64 do not generate debug info for tls var
...W_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, aarch64 does not emit DW_AT_Location for TLS variables.
>> I could see at this line, it says some restriction in aarch64 elf abi.
>>
>> https://github.com/llvm-mirror/llvm/blob/master/lib/Target/AArch64/AArch64TargetObjectFile.cpp#L24
>>
>>...
2020 Apr 15
4
Seeking clarification and way forward on limited scope variables.
...h “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
DW_AT_location (0x...
2020 Apr 15
2
Seeking clarification and way forward on limited scope variables.
...ned(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")
----------------------------------------------
Th...
2012 Jan 02
0
[LLVMdev] DW_AT_location not getting generated for local variables
I found the problem. The llvm.dbg.declare call must have a !dbg tag,
otherwise the location info is not generated. Changing the invocation
in my original example to "call void @llvm.dbg.declare(metadata !{i32*
%"bar:Int32"}, metadata !13), !dbg !16" causes MC to generate the
local location as expected.
-Joe
On Thu, Dec 29, 2011 at 12:41 PM, Joe Groff <arcata at
2018 Nov 01
4
Fwd: RFC: Adding debug information to LLVM to support Fortran
...xpr: !DIExpression())
!31 = 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
-----------...
2012 Mar 02
2
[LLVMdev] Question on debug information
...erated that targets x86 32-bit.
Reading dwarf symbol using
readelf --debug-dump check.o
I've got for 'n' parameter:
<2><71>: Abbrev Number: 3 (DW_TAG_formal_parameter)
<72> DW_AT_name : n
<74> DW_AT_type : <0xb3>
<78> DW_AT_location : 0x0 (location list)
I would have expected a DW_AT_location that is FP related and not 0x0.
Is my LL file incorrect ?
Is there something I can use in metadata to enforce a FP relative
DW_AT_location to be generated ?
Thanks for your answers
Best Regards
Seb
-------------- next part -----...
2012 Mar 06
0
[LLVMdev] Question on debug information
...g dwarf symbol using
> readelf --debug-dump check.o
>
> I've got for 'n' parameter:
>
> <2><71>: Abbrev Number: 3 (DW_TAG_formal_parameter)
> <72> DW_AT_name : n
> <74> DW_AT_type : <0xb3>
> <78> DW_AT_location : 0x0 (location list)
>
> I would have expected a DW_AT_location that is FP related and not 0x0.
> Is my LL file incorrect ?
> Is there something I can use in metadata to enforce a FP relative
> DW_AT_location to be generated ?
>
> Thanks for your answers
> Best Rega...