Displaying 7 results from an estimated 7 matches for "tag_vari".
Did you mean:
tag_val
2011 Dec 29
2
[LLVMdev] DW_AT_location not getting generated for local variables
..., metadata !5, i32 1, i32 1, metadata !7, i32 0}
; [ DW_TAG_lexical_block ]
!16 = metadata !{i32 2, i32 2, metadata !14, null}
!17 = metadata !{i32 3, i32 3, metadata !14, null}
!18 = metadata !{i32 4, i32 4, metadata !14, null}
---
And this is what dwarfdump on the compiled object file shows. The
TAG_variable entry for 'bar' is missing its AT_location.
---
----------------------------------------------------------------------
File: foo.o (x86_64)
----------------------------------------------------------------------
.debug_info contents:
0x00000000: Compile Unit: length = 0x000000a9 vers...
2012 Jan 02
0
[LLVMdev] DW_AT_location not getting generated for local variables
...7, i32 0}
> ; [ DW_TAG_lexical_block ]
> !16 = metadata !{i32 2, i32 2, metadata !14, null}
> !17 = metadata !{i32 3, i32 3, metadata !14, null}
> !18 = metadata !{i32 4, i32 4, metadata !14, null}
> ---
>
> And this is what dwarfdump on the compiled object file shows. The
> TAG_variable entry for 'bar' is missing its AT_location.
>
> ---
> ----------------------------------------------------------------------
> File: foo.o (x86_64)
> ----------------------------------------------------------------------
> .debug_info contents:
>
> 0x00000000: C...
2011 Oct 13
1
[LLVMdev] Local variable information in scope
Hi,
I want to list some additional information on this.
The variable collection I am looking at is, "variables 'declared' in scope".
1. When I traverse the MachineInstructions in the LexicalScopes ranges, and check for variables, I get variables used in this scope.
The variables listed include variables which may not have been declared in the scope. (for example
2008 Apr 23
3
[LLVMdev] Compile units in debugging intrinsics / globals
...int is not defined), and fn2 appears to be in
compile unit "file3". My dwarf records are therefore incorrect, appearing
something like
TAG_compile_unit "file1"
TAG_subprogram "fn1" ...
...
TAG_base_type "int" ...
TAG_compile_init "file2"
TAG_variable "a" ...
TAG_compile_unit "file3"
TAG_subprogram "fn2" ...
...
When, in fact, these compile units "file2" and "file3" are bogus and
everything should be part of compile_unit "file1".
My question is: can I tell that these three...
2019 Dec 03
2
addition of vendor dwarf operator extension.
Hello,
Thanks for prompt reply.
Motivation,
In case of debugging of bi-endian dwarf and value known at runtime some of the raw values needs to be byte swapped to change the endianity. We have a llvm based compiler which generates such dwarf, TAG_variable marked as big endian and debugging on little endian host using lldb. The listed operator on dwarf issues does that, one operator instead of list of operators.
Proposal,
Addition of listed dwarf operator as vender extension in llvm/lldb till it gets released.
Regards,
Chirag Patel
Software En...
2008 Apr 24
0
[LLVMdev] Compile units in debugging intrinsics / globals
...compile unit "file3". My dwarf records are therefore incorrect, appearing
> something like
>
> TAG_compile_unit "file1"
> TAG_subprogram "fn1" ...
> ...
> TAG_base_type "int" ...
>
> TAG_compile_init "file2"
> TAG_variable "a" ...
>
> TAG_compile_unit "file3"
> TAG_subprogram "fn2" ...
> ...
>
> When, in fact, these compile units "file2" and "file3" are bogus and
> everything should be part of compile_unit "file1".
this is n...
2019 Dec 02
3
addition of vendor dwarf operator extension.
Hello all,
There is one enhancement request open for dwarfv5, http://dwarfstd.org/ShowIssue.php?issue=191107.1
The request is for addition of dwarf expression operator to swap the top of the dwarf stack, the response seems positive but it may take some time till v6.
I like to add that operator as vendor extension but I am not sure how to go about it for llvm/lldb. Currently I am using it as