Displaying 20 results from an estimated 108 matches for "dw_at_type".
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
...# Abbrev [2] 0x22:0x5d DW_TAG_subprogram
> .int Linfo_string3 # DW_AT_name
> .byte 1 # DW_AT_decl_file
> .byte 2 # DW_AT_decl_line
> # DW_AT_prototyped
> .int 127 # DW_AT_type
> # DW_AT_external
> .int Lfunc_begin0 # DW_AT_low_pc
> .int Lfunc_end0 # DW_AT_high_pc
> .byte 2 # DW_AT_frame_base
> .byte 144
> .byte 60
> .byte 3 # Abbrev [3] 0x38...
2016 Mar 23
1
Clang/LLVM producing incomplete & erroneous debug information
...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
<2><c0>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<c1> DW_AT_location : 0x23 (location list)
<c5> DW_AT_name : (indirect string, offset: 0xc2)...
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
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
2018 Nov 01
4
Fwd: RFC: Adding debug information to LLVM to support Fortran
...LowerBound: 1, constUpperBound: 10)
!103 = !DIFortranSubrange(constLowerBound: 2, constUpperBound: 11)
The DWARF generated for this is as follows. (DWARF asserts in the standard
that arrays are interpreted as column-major.)
DW_TAG_array_type:
DW_AT_name: array
DW_AT_type: 4d08 ;TYPE(t)
DW_TAG_subrange_type:
DW_AT_type: int
DW_AT_lower_bound: 1
DW_AT_upper_bound: 10
DW_TAG_subrange_type:
DW_AT_type: int
DW_AT_lower_bound: 2
DW_AT_upper_bound: 11
2.2.2 Adjustable arrays
By adjustable arrays, we mean that an array may have its size passed
explicitly as anot...
2015 Nov 18
3
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...rogram (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) 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 (=...
2012 Feb 11
0
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...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
DW_AT_name int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 4
<1>&l...
2012 Feb 11
2
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...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
DW_AT_name int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 4
<1>&l...
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
...# DW_AT_name
.byte 0
.byte 5 # DW_AT_encoding
.byte 4 # DW_AT_byte_size
.byte 3 # Abbrev [3] 0x63:0x18 DW_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...
2016 Jan 19
2
RFC: Supporting all entities declared in lexical scope in LLVM debug info
...> 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_ty...
2018 Mar 23
2
Question about debug information for global variables
...-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] (<0xd> 03 b0
>> 2e 00 00 00 00 00 00 06 10 00 22 )
>>
>>
>> Without deref:
>&...
2015 Nov 13
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...; A<MONKEY> *p;
> };
>
> C c;
>
> This gives this DWARF:
>
> +-0000003f DW_TAG_structure_type "B"
> -DW_AT_name DW_FORM_strp "B"
> +-00000047 DW_TAG_member "p"
> -DW_AT_name DW_FORM_strp "p"
> +-DW_AT_type DW_FORM_ref4 0x00000054
> +-00000054 DW_TAG_pointer_type
> +-DW_AT_type DW_FORM_ref4 0x00000059
> +-00000059 DW_TAG_class_type "A<MONKEY>"
> -DW_AT_name DW_FORM_strp "A<MONKEY>"
> -DW_AT_declarati...
2018 Nov 01
2
RFC: Adding debug information to LLVM to support Fortran
...(constLowerBound: 1, constUpperBound: 10)
!103 = !DIFortranSubrange(constLowerBound: 2, constUpperBound: 11)
The DWARF generated for this is as follows. (DWARF asserts in the standard that arrays are interpreted as column-major.)
DW_TAG_array_type:
DW_AT_name: array
DW_AT_type: 4d08 ;TYPE(t)
DW_TAG_subrange_type:
DW_AT_type: int
DW_AT_lower_bound: 1
DW_AT_upper_bound: 10
DW_TAG_subrange_type:
DW_AT_type: int
DW_AT_lower_bound: 2
DW_AT_upper_bound: 11
2.2.2 Adjustable arrays
By adjustable arrays, we mean that an array may have its size passed explicitly as another argume...
2018 Mar 23
0
Question about debug information for global variables
...;
>>>
>>> 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] (<0xd> 03 b0
>>> 2e 00 00 00 00 00 00 06 10 00 22 )
>>>
>>>
>>&...
2015 Dec 09
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...; A<MONKEY> *p;
> };
>
> C c;
>
> This gives this DWARF:
>
> +-0000003f DW_TAG_structure_type "B"
> -DW_AT_name DW_FORM_strp "B"
> +-00000047 DW_TAG_member "p"
> -DW_AT_name DW_FORM_strp "p"
> +-DW_AT_type DW_FORM_ref4 0x00000054
> +-00000054 DW_TAG_pointer_type
> +-DW_AT_type DW_FORM_ref4 0x00000059
> +-00000059 DW_TAG_class_type "A<MONKEY>"
> -DW_AT_name DW_FORM_strp "A<MONKEY>"
> -DW_AT_declarati...
2017 Apr 04
2
GDB doesn't work with IR-originated debug info
...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 HORIZONTAL")
DW_AT_type [DW_FORM_ref_addr] (*0x000000006e440296*)
DW_
AT_external [DW_FORM_flag_present] (true)
In the original object file the corresponding record was:
0x00000296: DW_TAG_base_type [10]
DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] =
"void")...
2012 Feb 24
1
[LLVMdev] DW_AT_inline not present in assembly for an inlined inline function
...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 @ Abbrev [4] 0x87:0xa DW_TAG_subprogram
.byte 116 @ DW_AT_name
.byte 0
.byte 2 @ DW_AT_decl_file
.byte 2...
2015 Dec 09
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...; A<MONKEY> *p;
> };
>
> C c;
>
> This gives this DWARF:
>
> +-0000003f DW_TAG_structure_type "B"
> -DW_AT_name DW_FORM_strp "B"
> +-00000047 DW_TAG_member "p"
> -DW_AT_name DW_FORM_strp "p"
> +-DW_AT_type DW_FORM_ref4 0x00000054
> +-00000054 DW_TAG_pointer_type
> +-DW_AT_type DW_FORM_ref4 0x00000059
> +-00000059 DW_TAG_class_type "A<MONKEY>"
> -DW_AT_name DW_FORM_strp "A<MONKEY>"
> -DW_AT_declarati...
2016 Apr 30
2
Debug info scope of explicit casting type does not seem correct
...is behavior of creating debug info is correct.
A type in compile unit entry is pointing 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[0x...
2012 Oct 02
0
[LLVMdev] Wrong type qualifier for this pointer in case of ARM compiled binary
...DW_TAG_class_type)
<6c> DW_AT_name : (indirect string, offset: 0x3e): Simple
<70> DW_AT_byte_size : 1
<71> DW_AT_decl_file : 1
<72> DW_AT_decl_line : 1
[...]
<3><7f>: Abbrev Number: 8 (DW_TAG_formal_parameter)
<80> DW_AT_type : <0x86>
<84> DW_AT_artificial : 1
<84> DW_AT_object_pointer: 1
<1><86>: Abbrev Number: 9 (DW_TAG_pointer_type)
<87> DW_AT_type : <0x6b>
The "this" parameter has type "Simple *" as expected, but also has...