search for: dw_form_data1

...> .byte 46 # DW_TAG_subprogram > .byte 1 # DW_CHILDREN_yes > .byte 3 # DW_AT_name > .byte 14 # DW_FORM_strp > .byte 58 # DW_AT_decl_file > .byte 11 # DW_FORM_data1 > .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...

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

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

...Target triple: 'i686-w64-mingw32'. Looking this offset (1849950870 == 0x6e440296) in dwarfdump output of the dll gave the following: 0x00000296: DW_TAG_base_type [10] DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000068f] = "void") DW_AT_encoding [DW_FORM_data1] (0x00) DW_AT_byte_size [DW_FORM_data1] (0x00) .... 0x00000cf8: DW_TAG_subprogram [16] * DW_AT_low_pc [DW_FORM_addr] (0x000000006e384c30) DW_AT_high_pc [DW_FORM_data4] (0x000002b4) DW_AT_frame_base [DW_FORM_exprloc] (&...

...byref // variable's location. const TargetRegisterInfo *RI = Asm->TM.getRegisterInfo(); unsigned Reg = RI->getDwarfRegNum(Location.getReg(), false); DIEBlock *Block = new (DIEValueAllocator) DIEBlock(); if (Location.isReg()) { if (Reg < 32) addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_reg0 + Reg); else { Reg = Reg - dwarf::DW_OP_reg0; addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_breg0 + Reg); addUInt(Block, 0, dwarf::DW_FORM_udata, Reg); } } else { if (Reg < 32) addUInt(Block, 0, dwarf::DW_FORM_data1, dwarf::DW_OP_br...

...# Abbreviation Code .byte 36 # DW_TAG_base_type .byte 0 # DW_CHILDREN_no .byte 3 # DW_AT_name .byte 8 # DW_FORM_string .byte 62 # DW_AT_encoding .byte 11 # DW_FORM_data1 .byte 11 # DW_AT_byte_size .byte 11 # DW_FORM_data1 .byte 0 # EOM(1) .byte 0 # EOM(2) .byte 3 # Abbreviation Code .byte 52 # DW_TAG_variable .byte 0...

On Thu, Dec 15, 2016 at 11:35 AM Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Dec 15, 2016, at 10:54 AM, David Blaikie via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Branching off from a discussion of improvements to DIGlobalVariable > representations that Adrian's working on - got me thinking about related > changes that have

...elative to that unit. Should we emit unit-relative offsets instead? I've prototyped this and end up with output something like this: 0x00000051: DW_TAG_base_type [24] DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000051] = "int") DW_AT_encoding [DW_FORM_data1] (0x05) DW_AT_byte_size [DW_FORM_data1] (0x04) 0x00000058: NULL 0x000001ec: Compile Unit: length = 0x0000002b version = 0x0004 abbr_offset = 0x0000 addr_size = 0x08 (next unit at 0x0000021b) 0x0000000b: DW_TAG_type_unit [25] * DW_AT_language [DW_FORM_data2] (0x...

...G_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 [DW_FORM_data1] (16) Regards, Amjad From: David Blaikie [mailto:dblaikie at gmail.com] Sent: Saturday, April 30, 2016 17:59 To: Aboud, Amjad <amjad.aboud at intel.com> Cc: Adrian Prantl <a...

...G_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 [DW_FORM_data1] (16) 0x00000037: NULL command line: clang -cc1 -triple i386-apple-ios9.0.0 -emit-obj -debug-info-kind=limited -O2 test.cpp -o - | llvm-dwarfdump -debug-dump=info - > cat te...

...gt; .byte 1 # DW_CHILDREN_yes > > .byte 3 # DW_AT_name > > .byte 14 # DW_FORM_strp > > .byte 58 # DW_AT_decl_file > > .byte 11 # DW_FORM_data1 > > .byte 59 # DW_AT_decl_line > > .byte 11 # DW_FORM_data1 > > .byte 39 # DW_AT_prototyped > > .byte 25 # DW_FORM_flag_present > > .byte 73...

...G_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 [DW_FORM_data1] (16) Regards, Amjad From: David Blaikie [mailto:dblaikie at gmail.com<mailto:dblaikie at gmail.com>] Sent: Saturday, April 30, 2016 17:59 To: Aboud, Amjad <amjad.aboud at i...

Is there any good reason for using DW_FORM_data1 for the DW_AT_language attribute of DW_TAG_compile_unit? This prevents using language codes in the DW_LANG_lo_user=0x8000 to DW_LANG_hi_user=0xffff range. I think the obvious change to use DW_FORM_data2 in line 1897 of lib/CodeGen/AsmPrinter/DwarfDebug.cpp should fix it. Or, if there are binary co...

...DW_AT_ranges [DW_FORM_sec_offset] (0x00021960 [0x0000000000001878 - 0x000000000000187c) [0x00000000000018b0 - 0x0000000000001910) [0x0000000000001980 - 0x00000000000019e0)) DW_AT_call_file [DW_FORM_data1] ("<mypath>/testprogram_lucidDreams/iOS_APP/LucidDreams/DreamListViewControllerModel.swift") DW_AT_call_line [DW_FORM_data1] (61) while processing <mypath>/testprogram_lucidDreams/iOS_APP/DerivedData/iOS_APP/Build/Intermediates.noindex/iOS_APP.build/Debug-i...

...                    DW_AT_ranges [DW_FORM_sec_offset]    (0x00021960                       [0x0000000000001878 - 0x000000000000187c)                       [0x00000000000018b0 - 0x0000000000001910)                       [0x0000000000001980 - 0x00000000000019e0))                     DW_AT_call_file [DW_FORM_data1]    ("<mypath>/testprogram_lucidDreams/iOS_APP/LucidDreams/DreamListViewControllerModel.swift")                     DW_AT_call_line [DW_FORM_data1]    (61) while processing <mypath>/testprogram_lucidDreams/iOS_APP/DerivedData/iOS_APP/Build/Intermediates.noindex/iOS_APP.build/D...

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

...SubprogramDie.addAttribute(DW_AT_low_pc, DW_FORM_addr, 0x1000U); SubprogramDie.addAttribute(DW_AT_high_pc, DW_FORM_addr, 0x2000U); DwarfGenDIE IntDie = CUDie.addChild(DW_TAG_base_type); IntDie.addAttribute(DW_AT_name, DW_FORM_strp, "int"); IntDie.addAttribute(DW_AT_encoding, DW_FORM_data1, DW_ATE_signed); IntDie.addAttribute(DW_AT_byte_size, DW_FORM_data1, 4); DwarfGenDIE ArgcDie = SubprogramDie.addChild(DW_TAG_formal_parameter); ArgcDie.addAttribute(DW_AT_name, DW_FORM_strp, "argc"); //ArgcDie.addAttribute(DW_AT_type, DW_FORM_ref_addr, IntDie); // Crashes her...

...t point to the sections, not to labels inside these sections. e) Sections itself must be enclosed into braces > “.section .debug_info {…}” Again, why is this a limitation? >>>> i) .debug_frame section is emitted by txas compiler. > DW_AT_frame_base must be set to dwarf::DW_FORM_data1 > dwarf::DW_OP_call_frame_cfa value. I doubt that's a problem. Why is this a problem? On Tue, Nov 7, 2017 at 1:33 AM, Alexey Bataev via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: 06.11.2017 14:56, Robinson, Paul пишет: >> Hi everybod...

...cations to instructions, not labels. It > might or might not be easy to work around this; there might be an > unfortunate interaction with how emitting line-0 records works. > >> i) .debug_frame section is emitted by txas compiler. >>     DW_AT_frame_base must be set to dwarf::DW_FORM_data1 >> dwarf::DW_OP_call_frame_cfa value. > I doubt that's a problem. > >> j) Strings cannot be referenced by the labels, instead they must be >> inlined in the sections in form of array of chars. > LLVM used to do inline strings, but switched to the .debug_str section &g...

...ribute, but it can be appiled to pointer/reference types only, not variables. h) The first label in the function must follow the debug location macro. In LLVM, it is followed by the debug location macro. i) .debug_frame section is emitted by txas compiler. DW_AT_frame_base must be set to dwarf::DW_FORM_data1 dwarf::DW_OP_call_frame_cfa value. j) Strings cannot be referenced by the labels, instead they must be inlined in the sections in form of array of chars. Some changes in LLVM are required to support all these limitation/features in the output PTX files. Required changes in LLVM. =================...