[PATCH] D14210: CodeView type info support preview (Clang portion)
Dave Bartolomeo via cfe-commits
cfe-commits at lists.llvm.org
Fri Oct 30 11:45:02 PDT 2015
DaveBartolomeo created this revision.
DaveBartolomeo added a reviewer: majnemer.
DaveBartolomeo added a subscriber: cfe-commits.
This diff is a preview of the implementation of the Clang portion of the CodeView RFC being discussed on the llvm-dev and cfe-dev lists. The code isn't ready for detailed code review yet. There will likely be some changes to the design based on feedback, plus there's still a bit of code clean-up to do. Once the design is settled and I've got the code finalized, I'll break it up into more easily-digestible patches for official code review. For now, though, this diff should be useful to anyone who has read the RFC and wants to see some concrete details.
The primary Clang change is the addition of the CodeViewTypeTable class. This class provides several member functions for creating a CodeView type record to represent a particular Clang type. The actual emission of the records is handled by the instance of TypeTableBuilder passed to the constructor. The TypeIndex for each QualType is remembered to avoid duplicate work. Note that the type record for a user-defined type includes both the mangled name of the type and the "display name", which is the fully-qualified name of the type used for display purposes in the Visual Studio debugger.
The mangled name of each type is generated through the usual MangleContext. I did have to make a change to the Microsoft mangler to handle mangling of unprototyped functions, which can occur for local types declared within such a function.
The display name of each type is generated through a new class, DisplayNameGenerator. This class traverses the AST for the type to build the display name, requiring a few tricky gyrations to match the whitespace conventions used by the equivalent code in the Visual C++ compiler.
The CodeView information for bitfields has separate fields for the byte offset of the bitfield's "allocation unit" and the bit offset within that allocation unit. The concept of an allocation unit wasn't exposed from the ABI code before, but was relatively easy to add. The changes to RecordLayoutBuilder shouldn't affect the actual layout of any types; they just track where each allocation unit starts and what the allocation unit of each bitfield is.
Finally, I added the necessary code to CGDebugInfo to create a CodeViewTypeTable, demand type indices from it for types that need debug info, and emit those type indices and type records into the LLVM metadata.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 145311 bytes
Desc: not available
More information about the cfe-commits