Displaying 12 results from an estimated 12 matches for "dw_tag_array_type".
2018 Nov 01
4
Fwd: RFC: Adding debug information to LLVM to support Fortran
..., type: !5, flags:
DIFlagArtificial)
This will generate the following DWARF information.
DW_TAG_string_type:
DW_AT_name: character(*)!1
DW_AT_string_length: 0x9b (location list)
DW_AT_byte_size: 4
2.2 Fortran Array Types and Bounds In this section we refer to the DWARF
tag, DW_TAG_array_type, which is used to describe Fortran arrays. However
in Fortran, arrays are not types but are rather runtime data objects, a
multidimensional rectangular set of scalar data of homogeneous type. An
array object has dimensions (rank and corank) and extents in those
dimensions. The rank and ranges of t...
2020 Feb 13
3
Have the debugger show an away with a dynamic size?
Hi. I searched and the closest thing I could find was this
http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html
Currently a known sized array looks and debugs as expected. I use
llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size
field. In my language arrays are always passed around with a pointer and
size pair. I'd like debugging to show up as nicely instead of a pointer
addr with no information about the elements. How would I do this? I don't
use the C API, I output llvm-ir directly. I was hoping I ca...
2018 Jul 28
2
ThinLTO Bug ?
...positeType(tag: DW_TAG_class_type, file: !3,
templateParams: !6, scope: !8)
!6 = !{!7}
; The reference to @b and struct.TA.0 (renamed) that will be loaded in %a.o
!7 = !DITemplateValueParameter(value: i1 (%struct.TA*)* @b)
!8 = distinct !DISubprogram(unit: !2)
!9 = !DICompositeType(tag: DW_TAG_array_type, identifier: "SHARED", scope: !8)
2018 Jul 30
2
ThinLTO Bug ?
...> am quite new to this part of LLVM.
> >
> > 1. DICompositeType “SHARED” in a.ll is ODRed with the one in b.ll at load
> > time.
>
> I know relatively little about LTO but I see that in a.ll, "SHARED" is
> described as a DW_TAG_class_type while in b.ll it is DW_TAG_array_type.
> This suggests that you have an ODR violation in your source code.
>
Hi Paul
Thanks for pointing it out.
I fixed this by making in b.ll and the same failure persists.
!9 = !DICompositeType(tag: DW_TAG_class_type, file: !3, identifier:
"SHARED", scope: !8)
-Xin
> ODR violati...
2012 Feb 11
0
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 4
<1>< 141> DW_TAG_base_type
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_signed
<1>< 144> DW_TAG_array_type
DW_AT_type <134>
<2>< 149> DW_TAG_subrange_type
DW_AT_type <141>
DW_AT_upper_bound <141>1
[...]
gcc 3/4:
[...]
LOCAL_SYMBOLS:
[...]
<2>< 66> DW_TAG_...
2012 Feb 11
2
[LLVMdev] DW_TAG_base_type missing DW_AT_name for subrange types
...int
DW_AT_encoding DW_ATE_signed
DW_AT_byte_size 4
<1>< 141> DW_TAG_base_type
DW_AT_byte_size 4
DW_AT_encoding DW_ATE_signed
<1>< 144> DW_TAG_array_type
DW_AT_type <134>
<2>< 149> DW_TAG_subrange_type
DW_AT_type <141>
DW_AT_upper_bound <141>1
[...]
gcc 3/4:
[...]
LOCAL_SYMBOLS:
[...]
<2>< 66> DW_TAG_...
2018 Nov 01
2
RFC: Adding debug information to LLVM to support Fortran
...ould be nice to use a similar scheme here.
This will generate the following DWARF information.
DW_TAG_string_type:
DW_AT_name: character(*)!1
DW_AT_string_length: 0x9b (location list)
DW_AT_byte_size: 4
2.2 Fortran Array Types and Bounds
In this section we refer to the DWARF tag, DW_TAG_array_type, which is used to describe Fortran arrays.
However in Fortran, arrays are not types but are rather runtime data objects, a multidimensional rectangular set of scalar data of homogeneous type. An array object has dimensions (rank and corank) and extents in those dimensions. The rank and ranges of t...
2020 Feb 15
2
Have the debugger show an away with a dynamic size?
...m-dev at lists.llvm.org> wrote:
>
> Hi. I searched and the closest thing I could find was this
> http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html
>
> Currently a known sized array looks and debugs as expected. I use
> llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size
> field. In my language arrays are always passed around with a pointer and
> size pair. I'd like debugging to show up as nicely instead of a pointer
> addr with no information about the elements. How would I do this? I don't
> use the C API, I output llvm-ir directl...
2019 Nov 14
3
DW_OP_implicit_pointer design/implementation in general
On Thu, Nov 14, 2019 at 1:27 PM Adrian Prantl <aprantl at apple.com> wrote:
>
>
> > On Nov 14, 2019, at 1:21 PM, David Blaikie <dblaikie at gmail.com> wrote:
> >
> > Hey folks,
> >
> > Would you all mind having a bit of a design discussion around the
> feature both at the DWARF level and the LLVM implementation? It seems like
> what's
2014 Oct 14
2
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
...al_block
Tag = 258, Count = 1, Ops = 1, Name = DW_TAG_expression
Tag = 13, Count = 73880, Ops = 299110, Name = DW_TAG_member
Tag = 58, Count = 1387, Ops = 4161, Name = DW_TAG_imported_module
Tag = 1, Count = 2747, Ops = 21976, Name = DW_TAG_array_type
Tag = 46, Count = 1341021, Ops = 12069189, Name = DW_TAG_subprogram
Tag = 257, Count = 4373879, Ops = 20785065, Name = DW_TAG_arg_variable
Tag = 8, Count = 2246, Ops = 6738, Name = DW_TAG_imported_declaration
Tag = 53, Count = 57, Ops = 228, Name...
2019 Jan 19
2
What does "preds" mean in a .ll file?
Hi,
I see things like this. What does it mean? Is it documented somewhere? Thanks.
; preds = %for.body
https://llvm.org/docs/LangRef.html
; <label>:91: ; preds = %88
%92 = load i8**, i8*** @glob_complete_word.matches, align 8, !dbg !99798
%93 = load i32, i32* @glob_complete_word.ind, align 4, !dbg !99799
%94 = sext i32 %93 to i64, !dbg !99798
2014 Oct 13
9
[LLVMdev] [RFC] Less memory and greater maintainability for debug info IR
In r219010, I merged integer and string fields into a single header
field. By reducing the number of metadata operands used in debug info,
this saved 2.2GB on an `llvm-lto` bootstrap. I've done some profiling
of DW_TAGs to see what parts of PR17891 and PR17892 to tackle next, and
I've concluded that they will be insufficient.
Instead, I'd like to implement a more aggressive plan,