Displaying 20 results from an estimated 40 matches for "dw_form_ref4".
2014 Feb 19
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
....byte 59 # DW_AT_decl_line
> .byte 11 # DW_FORM_data1
> .byte 39 # DW_AT_prototyped
> .byte 25 # DW_FORM_flag_present
> .byte 73 # DW_AT_type
> .byte 19 # DW_FORM_ref4
> .byte 63 # DW_AT_external
> .byte 25 # DW_FORM_flag_present
> .byte 17 # DW_AT_low_pc
> .byte 1 # DW_FORM_addr
> .byte 18 # DW_AT_high_pc
> .byte 1...
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
2015 Nov 13
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...lt;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_declaration DW_FORM_fl...
2015 Dec 09
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...lt;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_declaration DW_FORM_fl...
2015 Dec 09
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...lt;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_declaration DW_FORM_fl...
2016 Apr 30
2
Debug info scope of explicit casting type does not seem correct
...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[0x00000060] = &q...
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
2016 May 07
2
Debug info scope of explicit casting type does not seem correct
Hi David,
OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope.
But how about that we are emitting a subprogram entry that has no attributes?
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[0x00000060] = "T")
DW_AT_decl_file [DW_FORM_data1] ("c:\temp\ICL\LB\retain.cpp")
DW_AT_decl_line [D...
2016 May 08
2
Debug info scope of explicit casting type does not seem correct
...;> wrote:
Hi David,
OK, I got that DIE in Compile Unit scope may point to a DIE in subprogram scope.
But how about that we are emitting a subprogram entry that has no attributes?
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[0x00000060] = "T")
DW_AT_decl_file [DW_FORM_data1] ("c:\temp\ICL\LB\retain.cpp")
DW_AT_decl_line [D...
2015 Dec 09
2
[PATCH] D14358: DWARF's forward decl of a template should have template parameters.
...lt;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_declaration DW_FORM_fl...
2018 Mar 23
2
Question about debug information for global variables
...objectfile.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:
>> 0x00000032...
2018 Mar 22
2
Question about debug information for global variables
...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] (<0xd> 03 b0
2e 00 00 00 00 00 00 06 10 00 22 )
Without deref:
0x00000032: DW_TAG_variable [2]
DW_AT_name [DW_FORM...
2018 Mar 23
0
Question about debug information for global variables
...t;
>>> 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 de...
2012 Mar 20
0
[LLVMdev] Runtime linker issue wtih X11R6 on i386 with -O3 optimization
...# Abbreviation Code
.byte 52 # DW_TAG_variable
.byte 0 # DW_CHILDREN_no
.byte 3 # DW_AT_name
.byte 8 # DW_FORM_string
.byte 73 # DW_AT_type
.byte 19 # DW_FORM_ref4
.byte 63 # DW_AT_external
.byte 12 # DW_FORM_flag
.byte 58 # DW_AT_decl_file
.byte 11 # DW_FORM_data1
.byte 59 # DW_AT_decl_line
.byte 11 # DW_FORM_data1
.byte 2...
2018 Mar 22
0
Question about debug information for global variables
...ify-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] (<0xd> 03 b0
> 2e 00 00 00 00 00 00 06 10 00 22 )
>
>
> Without deref:
> 0x00000032: DW_TAG_variable [2]
&g...
2011 Mar 30
0
[LLVMdev] More DWARF problems
...a DIE 0x00000592 that was referred by another DIE 0x00000883 but somehow DIE 0x00000592 was not emitted. This could be a bug in DwarfDebug.cpp or how debug info is generated by FE.
In DwarfDebug.cpp, you'll see code like
addDIEEntry(VariableSpecDIE, dwarf::DW_AT_specification, dwarf::DW_FORM_ref4, VariableDIE);
Here VariableSpecDIE is referring VariableDIE, but VariableDIE is missing from the output. There are other uses of DW_FORM_ref4 also. So check in our dwarfdump output what is 0x00000883 and set appropriate breakpoint in debugger and see why it is not reaching to DwarfDebug::emitDIE...
2014 Feb 20
2
[LLVMdev] [lldb-dev] How is variable info retrieved in debugging for executables generated by llvm backend?
....byte 11 # DW_FORM_data1
> > .byte 39 # DW_AT_prototyped
> > .byte 25 # DW_FORM_flag_present
> > .byte 73 # DW_AT_type
> > .byte 19 # DW_FORM_ref4
> > .byte 63 # DW_AT_external
> > .byte 25 # DW_FORM_flag_present
> > .byte 17 # DW_AT_low_pc
> > .byte 1 # DW_FORM_addr
> > .byte 18...
2013 Mar 09
1
[LLVMdev] Question about abstract subprograms in debug info
...at we don't want to do is process the
// concrete DIE twice.
if (DIE *AbsSPDIE = AbstractSPDies.lookup(SPNode)) {
// Pick up abstract subprogram DIE.
SPDie = new DIE(dwarf::DW_TAG_subprogram);
SPCU->addDIEEntry(SPDie, dwarf::DW_AT_abstract_origin,
dwarf::DW_FORM_ref4, AbsSPDIE);
SPCU->addDie(SPDie);
}
…
}
The compile unit DIE where AbsSPDIE belongs to is different from the compile unit DIE SPCU->getCUDie().
So it is not legal to use a FORM_ref4 here.
Why do we create these subprogram DIEs here? They are added to SPCU, but not inserted via insertDI...
2011 Mar 30
5
[LLVMdev] More DWARF problems
I've been trying to track down the problem with the DWARF info that is being
emitted by my front end, which has been broken for about a month now. Here's
what happens when I attempt to use gdb to debug one of my programs on OS X:
gdb stack crawl at point of internal error:
[ 0 ] /usr/libexec/gdb/gdb-i386-apple-darwin (align_down+0x0) [0x122300]
[ 1 ] /usr/libexec/gdb/gdb-i386-apple-darwin