This only translates data members for now. Translating overloaded
methods is complicated, so I stopped short of doing that.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Please see the below comments.
By the way, once you commit this patch, I can help you complete the support for classes, I have a working solution...but need couple of days to apply it to the top of trunk.
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1014 ↗ | (On Diff #59419) | I would move the FieldListRecord building to separate function call it: Reason: this code will get larger once we support methods, so better leave creating the ClassRecord clear. |
1033 ↗ | (On Diff #59419) | Add a comment: |
1043 ↗ | (On Diff #59419) | When you said nested types, did you mean DW_TAG_inheritance? or other cases? |
1054 ↗ | (On Diff #59419) | Why do we need to count the SubRecords, while we could use: Ty->getElements().size()? |
1067 ↗ | (On Diff #59419) | I believe that it is not correct to always generate a FwdDecl record. David, can you confirm my assumption? |
Thanks, I actually rearchitected things significantly.
We're going to need some way to iterate all the record types, BTW. I'm not sure how to do that in the current metadata scheme.
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1014 ↗ | (On Diff #59419) | Yeah, that's a good idea. It also makes it easier to split union and class/struct handling while still sharing most of the code. |
1043 ↗ | (On Diff #59419) | No, this sort of thing: struct A { struct Nested {}; }; We have to change the output of Clang to mention these so that the ClassRecord for A always mentions A::Nested, otherwise the complete class definitions will not merge during type stream merging. |
1054 ↗ | (On Diff #59419) | Hm, this is actually wrong currently. MSVC counts the number of members, counting each overload separately, not the number of records in the field list. I'm not sure we should use getElements().size(), though, given that we skip lowering things like member functions currently. We should probably count members manually in lowerRecordFieldList. I'll do that. |
1067 ↗ | (On Diff #59419) | Huh, you're right. It looks like all intra-type stream type references use the forward decl, but the symbol stream may refer to the complete type index. I'm going to try to address this now, it seems important. |
Few more comments.
Reid, I can help you improve the record handling, so let's just solve the easy and urgent issues.
I will upload a followup patch that show you how we can get most of the information about records from current metadata.
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1025 ↗ | (On Diff #59483) | At this point you better check if the Ty->isForwardDecl(), if it is the case we should not create a complete class. |
1127 ↗ | (On Diff #59483) | This comment is confusing me, I do not understand why it is needed! |
1159 ↗ | (On Diff #59483) | I think this check is too later, we need to check that we did not create this complete record before the switch, i.e. at line 1140. |
It sounds like you think this is pretty close to OK and you want to write followups, so I'm going to land this now and give you a chance to do that. I need to spend the next few days dealing with an llvm-symbolizer issue, so go for it.
lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1025 ↗ | (On Diff #59483) | I can do this in getCompleteTypeIndex to share the code. |
1127 ↗ | (On Diff #59483) | David Blaikie asked me to add it. Let me move it above to the find lookup. |
1159 ↗ | (On Diff #59483) | Oops, this was the result of a late refactoring to avoid having two tag switches. It actually doesn't pass tests. :( Fixed. |
llvm/trunk/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp | ||
---|---|---|
1173 | I am not very much familiar with DenseMap, but I guess that the iterator we are holding in InsertResult.first might not remain valid in case we insert a new entry to CompleTypeIndices, which could happen while creating the complete class. For example, when we have nested classes. |
I am not very much familiar with DenseMap, but I guess that the iterator we are holding in InsertResult.first might not remain valid in case we insert a new entry to CompleTypeIndices, which could happen while creating the complete class. For example, when we have nested classes.