search for: dicompositetype

Is there a more convenient way to obtain a DIType given a Type than matching up the strings for the names? For example, given: struct S { int x, y; } s; void foo(S *a) { a->x = 0; a->y = 1; } There are DIType nodes for the struct Type: !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !3, line: 1, size: 64, flags: DIFlagTypePassByValue, elements: !7, identifier: "_ZTS1S") !7 = !{!8, !10} !8 = !DIDerivedType(tag: DW_TAG_member, name: "x", scope: !6, file: !3, line: 2, baseType: !9, size: 32) !9 = !DIBasicT...

...gt; My understanding why this is happening is roughly as follow. I would > > like to check with people whether this is a real bug. And also would > > like to help fixing it with other people’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 so...

...ERROR: Broken function found, compilation aborted! My understanding why this is happening is roughly as follow. I would like to check with people whether this is a real bug. And also would like to help fixing it with other people’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. 2. %struct.TA.0 (renamed from %struct.TA at load time) = type opaque and i1 (%struct.TA.0*)* @b in b.ll gets pulled into the destination module when we are merging in a.ll. 3. We only found out that %struct.TA.0 maps to %struct.TA when w...

...ea to add DIDescriptorRef (it makes our >> > types >> > loose) and am not sure about the 2nd condition. >> > >> > So I proposed to add DITypeArray (or DITypedArray<DITypeRef> as David >> > suggested, where all elements are DITypeRef), >> > DICompositeType::getTypeArray() will return DITypeArray and >> > DITypeArray::getElement(unsigned) will return DITypeRef. >> > >> > This is actually more complicated than I thought, not all >> > DICompositeType's >> > getTypeArray() can return an array of DITypeRefs...

...effects... but not the desired one). But there ought to be a way to get coalescing in the right places. We just need to ensure that the uniqued/coalesced parts of the graph: - are acyclic, and - reference only coalesced nodes (note that leaves can happily include the strangely-coalesced distinct DICompositeType beast I created). I've been thinking idly whether we can/should break DISubprogram apart into uniqued (coalesce-able) and distinct parts. Still being someone ignorant of DWARF itself (and CodeView, for that matter), I'm not entirely sure. But... Here's my understanding of the curren...

It's now a multi-stage process. First, there is a difference between a permanent forward declaration (i.e. the actual definition is in a different file) and a temporary forward declaration (i.e. it will appear later in the same file). To create a permanent forward declaration: DICompositeType *result = m_DIBuilder->createForwardDecl( dwarf::DW_TAG_structure_type, name, m_DICompileUnit, file, loc.m_Line); To create a temporary forward declaration: DICompositeType *result = m_DIBuilder->createReplaceableCompos...

...t; one). > > But there ought to be a way to get coalescing in the right places. We > just need to ensure that the uniqued/coalesced parts of the graph: > - are acyclic, and > - reference only coalesced nodes (note that leaves can happily include the > strangely-coalesced distinct DICompositeType beast I created). > Perhaps before I dive into your suggestion (which, it seems, is to separate out the definition but let the declaration/locals form cycles - that would at least be dropped because the definition would only be kept due to it being referenced from the llvm::Function), what abou...

...lso possible this is not a regression from my recent work, but that would be harder to recover from; let's hope it was from me.) -- I'm also concerned about the semantics of a particular case that I learned debugging correctness issues. If a type is defined inside a function, we create a DICompositeType (CT) whose "scope:" is the DISubprogram (SP) for that function's definition. This SP is not part of the type graph, it's the actual definition that eventually describes the code. However, the CT has an ODR identifier, which means it will get uniqued by the DITypeMap. This seems...

Before metadata was separated from values, I could create a debug info forward declaration and eventually resolve it using LLVMReplaceAllUsesWith in core.h. Now, I can't figure out how to resolve it. I can find no function that seems to do this. My one wild guess that giving the forward decl and the resolving decl the same UniqueId might do it is not working. I am currently using 3.6.1, but

...nly when dealing with class/structure bitfields: DwarfUnit::constructMemberDIE. Dumping align information everywhere only for 1 case looks like overhead to me. Consider the following code: struct S { char c; } s; When compiled with debug enabled in IR we get smth like that: !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !5, line: 1, size: 8, align: 8, elements: !7) Am I missing something? What is the purpose of "align: 8" here? Maybe we could include alignment information into DI* objects only when required (and thus dump it only when required):...

.... >> >> But there ought to be a way to get coalescing in the right places. We just need to ensure that the uniqued/coalesced parts of the graph: >> - are acyclic, and >> - reference only coalesced nodes (note that leaves can happily include the strangely-coalesced distinct DICompositeType beast I created). > > Perhaps before I dive into your suggestion (which, it seems, is to separate out the definition but let the declaration/locals form cycles No (new) cycles; in fact this breaks some. - the Function itself references the defn and the locals; - the locals and the defn ref...

...) /* isLocalToUnit */, false /* isDefinition */, 0, 0 /* VK, Index */, DIType(), false /* isArtificial */, false /* isOptimized */, f); DASSERT(sp.Verify()); } return sp; } And here's the code that generates function type descriptors: DICompositeType CodeGenerator::genDIFunctionType(const FunctionType * type) { DIDescriptorArray args; args.push_back(genDIType(type->returnType())); if (type->selfParam() != NULL) { const ParameterDefn * param = type->selfParam(); // genDIParameterType() calls genDIType and then makes it a...

...}; > >> -- > >> However, the DISubprogram(isDefinition: false) for S::foo will not be > >> structurally equivalent (since the 'file:' node won't match), so we > >> currently end up with two metadata nodes. The same thing happens for > >> the DICompositeType for `S` (and also applies to any fields). > >> > >> The checked-in testcase confirms that the description of `S` only has > >> one copy of `S::foo` in the DWARF output. (The testcase doesn't provide > >> good enough coverage actually; it gets lucky because t...

...const FunctionDefn * fn, (...) >         false /* isDefinition */, (...) Hi Talin, The only difference from what I'm doing is that I only export debug symbols in definitions, not declarations. I may be doing wrong, though, for multi-file compilation (haven't tested thoroughly). > DICompositeType CodeGenerator::genDIFunctionType(const FunctionType * type) (...) >   for (ParameterList::const_iterator it = params.begin(); it != > params.end(); ++it) { >     const ParameterDefn * param = *it; >     args.push_back(genDIParameterType(param->type())); >   } Don't do that. I...

Hi. I searched and the closest thing I could find was this http://lists.llvm.org/pipermail/llvm-dev/2018-February/121348.html Currently a known sized array looks and debugs as expected. I use llvm.dbg.declare with DICompositeType tag: DW_TAG_array_type and the size field. In my language arrays are always passed around with a pointer and size pair. I'd like debugging to show up as nicely instead of a pointer addr with no information about the elements. How would I do this? I don't use the C API, I output llvm-ir dire...

...of DIDescriptorRef. > I don't think it is a good idea to add DIDescriptorRef (it makes our types > loose) and am not sure about the 2nd condition. > > So I proposed to add DITypeArray (or DITypedArray<DITypeRef> as David > suggested, where all elements are DITypeRef), > DICompositeType::getTypeArray() will return DITypeArray and > DITypeArray::getElement(unsigned) will return DITypeRef. > > This is actually more complicated than I thought, not all DICompositeType's > getTypeArray() can return an array of DITypeRefs. For example, > getTypeArray() of ArrayType an...

...ef>, metadata <badref>, metadata !"fn_t", i32 5, i64 0, i64 0, i64 0, i32 0, metadata <badref>} ; [ DW_TAG_typedef ] [fn_t] [line 5, size 0, align 0, offset 0] [from ] as the function type parameter to DIBuilder::createFunction, due to this check in DebugInfo.cpp: 486 DICompositeType Ty = getType(); 487 if (!Ty.Verify()) 488 return false; Is it in fact wrong to pass a typedef here? Thanks, Duncan.

This isn't a realistic/viable implementation, just a hacked up "can I make it produce the right output" kind of thing, but while I hammer out a few more details (like fixing MC to allow multiple sections with the same name but different comdat groups) I figured I'd throw it out there to have a bit of a chat about it. I've tested simple cases of a single type and they seem to

...nly in 1 case. I am trying to make it so that it is dumped only when it is necessary. >> Consider the following code: >> >> struct S { >> char c; >> } s; >> >> When compiled with debug enabled in IR we get smth like that: >> >> !6 = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "S", file: !5, line: 1, size: 8, align: 8, elements: !7) >> >> Am I missing something? What is the purpose of "align: 8" here? Maybe we could include alignment information into DI* objects only when required (and thus dump it only wh...

...ibes the structure information? 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, whil...