search for: dw_tag_pointer_type

Hi, I am wondering if this 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...

...ram [2] * // f2 0x00000051: DW_TAG_lexical_block [3] 0x00000062: DW_TAG_structure_type [4] 0x0000006b: DW_TAG_subprogram [5] * // f1 0x00000087: DW_TAG_template_type_parameter [6] 0x0000008e: DW_TAG_lexical_block [7] * 0x0000009f: DW_TAG_variable [8] 0x000000ab: DW_TAG_pointer_type [9] // foo* & in fact, if you introduce another template that's similar to f1, its variable's type is 0x00ab - so it points into f1's children. Seems GCC puts it in whatever scope first references the pointer type. I think it's probably as sensible, and a bit simpler, to...

...W_AT_byte_size > .byte 5 # Abbrev [5] 0x86:0x7 DW_TAG_base_type > .int Linfo_string7 # DW_AT_name > .byte 6 # DW_AT_encoding > .byte 1 # DW_AT_byte_size > .byte 6 # Abbrev [6] 0x8d:0x5 DW_TAG_pointer_type > .int 134 # DW_AT_type > .byte 6 # Abbrev [6] 0x92:0x5 DW_TAG_pointer_type > .int 141 # DW_AT_type > .byte 0 # End Of Children Mark > L.debug_info_end0: > .section .debug_abbrev,"", at...

That happens because we create the subprogram below as a context to the “DW_TAG_typedef” that was created as a type to “DW_TAG_pointer_type” that was added to the retained type list because of the explicit cast to (T*). This is the code that creates DW_TAG_subprogram: DIE *DwarfUnit::getOrCreateSubprogramDIE(const DISubprogram *SP, bool Minimal) { ... // DW_TAG_inlined_subroutine may refer to this DIE. DIE &SPDie = createAn...

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

...gt; 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_flag_present > > +-00000073 DW_TAG_structure_type...

...gt; 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_flag_present > > +-00000073 DW_TAG_structure_type...

...ine: 47, isOptimized: false, unit: !1, variables: !73) !61 = !DIFile(filename: "test.zig", directory: "/home/andy/dev/zig/build") !62 = !DISubroutineType(types: !63) !63 = !{!64, !65} !64 = !DIBasicType(name: "void", encoding: DW_ATE_unsigned) !65 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&[]const u8", baseType: !66, size: 64, align: 64) !66 = !DICompositeType(tag: DW_TAG_structure_type, name: "[]u8", size: 128, align: 64, elements: !67) !67 = !{!68, !71} !68 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", scope: !66, baseType: !69, size:...

...{ ... } ------ According to the C standard, both arguments will be passed to the function as pointers. However, in the debug information metadata generated in LLVM, it appears that they are also equivalent. More specifically, for both arg_ptr and arg_arr I get a derived type descriptor with the DW_TAG_pointer_type tag, referencing 'int' as the type derived from, in argument 8 of the relevant MDNode. There is no way to know arg_arr is in the user's eyes an array. This reflects the compiler's view of things correctly, but is problematic for a debugger. The debugger should know that arg_arr ref...

...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 the attribute DW_AT_object_pointer. My guess is that the x86 gdb decides to print it as "const" because of this, but the ARM one doesn't. Hope th...

Hi All, Was looking into a simple program - class Simple { public: void fun() {} }; int main() { Simple s; s.fun(); return 0; } When compiled using clang++ for ARM- Expected result when we run - print Simple::fun in GDB is void fun(Simple* const this) as this should be a const pointer but in case of arm compiled binary we get void fun(Simple* this). Works fine when compiled using

...gt; 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_flag_present > > +-00000073 DW_TAG_structure_type...

...e, unit: !1, variables: !33) !27 = !DIFile(filename: "zigrt.zig", directory: "/home/andy/dev/zig/build/lib/zig/std/special") !28 = !DISubroutineType(types: !29) !29 = !{!30, !31, !32} !30 = !DIBasicType(name: "void", encoding: DW_ATE_unsigned) !31 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&const u8", baseType: !6, size: 64, align: 64) !32 = !DIBasicType(name: "usize", size: 64, encoding: DW_ATE_unsigned) !33 = !{!34, !35} !34 = !DILocalVariable(name: "message_ptr", arg: 1, scope: !26, file: !27, line: 7, type: !31) !35 = !DILocalVariable(nam...

..., scopeLine: 10, isOptimized: false, unit: !1, variables: !17) !5 = !DIFile(filename: "test.zig", directory: "/home/andy/dev/zig/build") !6 = !DISubroutineType(types: !7) !7 = !{!8, !9} !8 = !DIBasicType(name: "void", encoding: DW_ATE_unsigned) !9 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&[]const u8", baseType: !10, size: 64, align: 64) !10 = !DICompositeType(tag: DW_TAG_structure_type, name: "[]u8", size: 128, align: 64, elements: !11) !11 = !{!12, !15} !12 = !DIDerivedType(tag: DW_TAG_member, name: "ptr", scope: !10, baseType: !13, size:...

...gt; 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_flag_present > > +-00000073 DW_TAG_structure_type...

...lename: "zigrt.zig", directory: >> "/home/andy/dev/zig/build/lib/zig/std/special") >> !28 = !DISubroutineType(types: !29) >> !29 = !{!30, !31, !32} >> !30 = !DIBasicType(name: "void", encoding: DW_ATE_unsigned) >> !31 = !DIDerivedType(tag: DW_TAG_pointer_type, name: "&const u8", >> baseType: !6, size: 64, align: 64) >> !32 = !DIBasicType(name: "usize", size: 64, encoding: DW_ATE_unsigned) >> !33 = !{!34, !35} >> !34 = !DILocalVariable(name: "message_ptr", arg: 1, scope: !26, file: >> !27, l...

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

...; > According to the C standard, both arguments will be passed to the function as pointers. However, in the debug information metadata generated in LLVM, it appears that they are also equivalent. > > More specifically, for both arg_ptr and arg_arr I get a derived type descriptor with the DW_TAG_pointer_type tag, referencing 'int' as the type derived from, in argument 8 of the relevant MDNode. There is no way to know arg_arr is in the user's eyes an array. > > This reflects the compiler's view of things correctly, but is problematic for a debugger. The debugger should know that a...

> -----Original Message----- > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Tim > Northover via llvm-dev > Sent: Wednesday, July 25, 2018 3:07 AM > To: Nat! > Cc: LLVM Developers Mailing List > Subject: Re: [llvm-dev] A question to the DWARF experts on symbol > indirection > > Hi Nat!, > > On Wed, 25 Jul 2018 at 01:21, Nat! via