search for: dw_tag_class_type

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those three DWARF tags. Downstream object consumers that check to verify that a DWARF attr is appropri...

...t have such a mode, and the DWARF specification does not require it. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider, Todd via llvm-dev Sent: Tuesday, July 30, 2019 12:59 PM To: llvm-dev Subject: Re: [llvm-dev] Invalid DW_AT_calling_convention generated for a DW_TAG_class_type I see now that this is a DWARF 5 addition. It is still invalid for DWARF 4 or earlier. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Snider, Todd via llvm-dev Sent: Tuesday, July 30, 2019 11:54 AM To: llvm-dev Subject: [EXTERNAL] [llvm-dev] Invalid DW_AT_calling_conventi...

...ople’s help if it’s a real bug. I > > 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&quot...

...d like to describe them here and get some advice on what I might be doing wrong. #1) Class sizes coming out as zero. In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: DICompositeType di = dbgFactory_.CreateCompositeTypeEx( type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : dwarf::DW_TAG_structure_type, dbgCompileUnit_, type->typeDefn()->linkageName().c_str(), genDIFile(type->typeDefn()), getSourceLineNumber(type->typeDefn()->location()), getSizeOfInBits(type->irType()), getAlignOfInBits(type->irType()),...

...!{!2} !0 = !{i32 2, !"Debug Info Version", i32 3} !1 = !{i32 1, !"ThinLTO", i32 0} !2 = distinct !DICompileUnit(language: DW_LANG_C_plus_plus, file: !3, retainedTypes: !4) !3 = !DIFile(filename: "f2", directory: "") !4 = !{!5} !5 = !DICompositeType(tag: DW_TAG_class_type, file: !3, flags: DIFlagFwdDecl, identifier: "SHARED") !6 = distinct !DISubprogram(unit: !2) [~/thinltobug]$ cat b.ll target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %struct.TA = type opaque @gv = exter...

...t some advice on what I might be doing wrong. > > #1) Class sizes coming out as zero. > > In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: > > DICompositeType di = dbgFactory_.CreateCompositeTypeEx( > type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : dwarf::DW_TAG_structure_type, > dbgCompileUnit_, > type->typeDefn()->linkageName().c_str(), > genDIFile(type->typeDefn()), > getSourceLineNumber(type->typeDefn()->location()), > getSizeOfInBits(type->irType()), > getAlignOfIn...

...get some advice on what I might be doing wrong. > > #1) Class sizes coming out as zero. > > In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: > > DICompositeType di = dbgFactory_.CreateCompositeTypeEx( > type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : > dwarf::DW_TAG_structure_type, > dbgCompileUnit_, > type->typeDefn()->linkageName().c_str(), > genDIFile(type->typeDefn()), > getSourceLineNumber(type->typeDefn()->location()), > getSizeOfInBits(type->irType()), > getAlig...

...t be doing wrong. >> >> #1) Class sizes coming out as zero. >> >> In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: >> >> DICompositeType di = dbgFactory_.CreateCompositeTypeEx( >> type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : dwarf::DW_TAG_structure_type, >> dbgCompileUnit_, >> type->typeDefn()->linkageName().c_str(), >> genDIFile(type->typeDefn()), >> getSourceLineNumber(type->typeDefn()->location()), >> getSizeOfInBits(type->irType()), &gt...

...ight be doing wrong. >> >> #1) Class sizes coming out as zero. >> >> In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: >> >> DICompositeType di = dbgFactory_.CreateCompositeTypeEx( >> type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : >> dwarf::DW_TAG_structure_type, >> dbgCompileUnit_, >> type->typeDefn()->linkageName().c_str(), >> genDIFile(type->typeDefn()), >> getSourceLineNumber(type->typeDefn()->location()), >> getSizeOfInBits(type->irTyp...

...formation? For example: %2 = getelementptr inbounds %"class.std::thread", %"class.std::thread"* %this, i64 0, i32 0, i32 0, !dbg !2748 then I know the pointer operand type is class.std::thread. I want to find the associated metadata of this type: !217 = !DICompositeType(tag: DW_TAG_class_type, name: "thread", scope: !34, file: !218, line: 60, size: 64, align: 64, elements: !219, identifier: "_ZTSSt6thread") The challenge is that the structure name is different in the IR instruction, from the one in the metadata. One is class.std::thread, while another is _ZTSSt6thr...

..._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 "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member &...

...;> >>> #1) Class sizes coming out as zero. >>> >>> In my frontend, I call DebugFactory::CreateCompositeTypeEx as follows: >>> >>> DICompositeType di = dbgFactory_.CreateCompositeTypeEx( >>> type->typeClass() == Type::Class ? dwarf::DW_TAG_class_type : >>> dwarf::DW_TAG_structure_type, >>> dbgCompileUnit_, >>> type->typeDefn()->linkageName().c_str(), >>> genDIFile(type->typeDefn()), >>> getSourceLineNumber(type->typeDefn()->location()), >>> getSiz...

..._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 "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member &...

...(= "foo") DW_AT_low_pc DW_AT_low_high (2) LexicalBlock DW_AT_low_pc DW_AT_low_high (3) DW_TAG_imported_module DW_AT_import (=> N) (3) DW_TAG_imported_declaration DW_AT_import (=> N::D) (3) DW_TAG_typedef DW_AT_name (= "A") DW_AT_type (=> int) (3) DW_TAG_class_type DW_AT_name (= "B") (4) DW_TAG_variable DW_AT_name (= "x") DW_AT_type (= int) (3) DW_TAG_variable DW_AT_name (= "y") DW_AT_type (=> B) DW_AT_location (3) DW_TAG_variable DW_AT_name (= "z") DW_AT_type (= A) DW_AT_location Case (b) - T...

.... > Seems to be problem with qualifier type but was wondering how is this > target dependent? I think it's the gdb programs that are printing different things for the same DWARF debug information. Dumping the information from the x86 binary gives: <1><6b>: Abbrev Number: 6 (DW_TAG_class_type) <6c> DW_AT_name : (indirect string, offset: 0x3e): Simple <70> DW_AT_byte_size : 1 <71> DW_AT_decl_file : 1 <72> DW_AT_decl_line : 1 [...] <3><7f>: Abbrev Number: 8 (DW_TAG_formal_parameter) <80> DW_AT_type...

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

...are unusual so it would > save the performance cost a lot of the time right there. > > I don't know enough about Obj-C to say whether it can know up front > there are potentially other methods elsewhere. Another way to do the objective C solution would be to have an attribute on a DW_TAG_class_type that could specify a list of DIEs that are not contained in the class definition that are required for the class. In Objective C, the DW_TAG_subprogram for methods are outside of the class itself. This would involve DWARF changes, but it could be an attribute that specifies a section offset into a...

..._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 "C" > -DW_AT_name DW_FORM_strp "C" > +-0000007b DW_TAG_member &...

...> > > (3) DW_TAG_imported_module > > DW_AT_import (=> N) > > > > (3) DW_TAG_imported_declaration > > DW_AT_import (=> N::D) > > > > (3) DW_TAG_typedef > > DW_AT_name (= "A") > > DW_AT_type (=> int) > > > > (3) DW_TAG_class_type > > DW_AT_name (= "B") > > > > (4) DW_TAG_variable > > DW_AT_name (= "x") > > DW_AT_type (= int) > > > > (3) DW_TAG_variable > > DW_AT_name (= "y") > > DW_AT_type (=> B) > > DW_AT_location > > > &...

...xperimenting I was also interested to see that for DWARF and constructor homing, we emit skeleton type definitions if functions have an inlined copy in the translation unit. For example in [0] where I've uploaded a couple of dexter tests for constructor homing, in partial-type/main.cpp we get: DW_TAG_class_type DW_AT_name ("foo") DW_AT_declaration (true) DW_TAG_subprogram DW_AT_linkage_name ("_ZNK3foo8asStringB5cxx11Ev") DW_AT_name ("asString") DW_AT_decl_file ("./theclass.h") DW_AT_decl_line (12) DW_AT_type...