2015-12-25 02:51:35 +08:00
|
|
|
add_llvm_library(LLVMDebugInfoCodeView
|
2016-05-26 04:37:03 +08:00
|
|
|
CodeViewError.cpp
|
2016-11-03 01:05:19 +08:00
|
|
|
CodeViewRecordIO.cpp
|
2016-10-08 05:34:46 +08:00
|
|
|
CVSymbolVisitor.cpp
|
2017-01-11 08:35:43 +08:00
|
|
|
CVTypeDumper.cpp
|
2016-06-17 02:22:27 +08:00
|
|
|
CVTypeVisitor.cpp
|
2016-06-02 13:07:49 +08:00
|
|
|
EnumTables.cpp
|
LLVM CodeView library
Summary: This diff is the initial implementation of the LLVM CodeView library. There is much more work to be done, namely a CodeView dumper and tests. This patch should help others make progress on the LLVM->CodeView debug info emission while I continue with the implementation of the dumper and tests.
This library implements support for emitting debug info in the CodeView format. This phase of the implementation only includes support for CodeView type records. Clients that need to emit type records will use a class derived from TypeTableBuilder. TypeTableBuilder provides member functions for writing each kind of type record; each of these functions eventually calls the writeRecord virtual function to emit the actual bits of the record. Derived classes override writeRecord to implement the folding of duplicate records and the actual emission to the appropriate destination. LLVMCodeView provides MemoryTypeTableBuilder, which creates the table in memory. In the future, other classes derived from TypeTableBuilder will write to other destinations, such as the type stream in a PDB.
The rest of the types in LLVMCodeView define the actual CodeView type records and all of the supporting enums and other types used in the type records. The TypeIndex class is of particular interest, because it is used by clients as a handle to a type in the type table.
The library provides a relatively low-level interface based on the actual on-disk format of CodeView. For example, type records refer to other type records by TypeIndex, rather than by an actual pointer to the referent record. This allows clients to emit type records one at a time, rather than having to keep the entire transitive closure of type records in memory until everything has been emitted. At some point, having a higher-level interface layered on top of this one may be useful for debuggers and other tools that want a more holistic view of the debug info. The lower-level interface should be sufficient for compilers and linkers to do the debug info manipulation that they need to do efficiently.
Reviewers: rnk, majnemer
Subscribers: silvas, rnk, jevinskie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14961
llvm-svn: 256385
2015-12-25 02:12:38 +08:00
|
|
|
Line.cpp
|
2016-06-03 11:25:59 +08:00
|
|
|
ModuleSubstream.cpp
|
|
|
|
|
ModuleSubstreamVisitor.cpp
|
2016-05-13 01:45:44 +08:00
|
|
|
RecordSerialization.cpp
|
2016-12-17 06:48:14 +08:00
|
|
|
SymbolRecordMapping.cpp
|
2016-05-24 07:41:13 +08:00
|
|
|
SymbolDumper.cpp
|
2017-01-11 08:35:08 +08:00
|
|
|
TypeDatabase.cpp
|
|
|
|
|
TypeDatabaseVisitor.cpp
|
[CodeView] Finish decoupling TypeDatabase from TypeDumper.
Previously the type dumper itself was passed around to a lot of different
places and manipulated in ways that were more appropriate on the type
database. For example, the entire TypeDumper was passed into the symbol
dumper, when all the symbol dumper wanted to do was lookup the name of a
TypeIndex so it could print it. That's what the TypeDatabase is for --
mapping type indices to names.
Another example is how if the user runs llvm-pdbdump with the option to
dump symbols but not types, we still have to visit all types so that we
can print minimal information about the type of a symbol, but just without
dumping full symbol records. The way we did this before is by hacking it
up so that we run everything through the type dumper with a null printer,
so that the output goes to /dev/null. But really, we don't need to dump
anything, all we want to do is build the type database. Since
TypeDatabaseVisitor now exists independently of TypeDumper, we can do
this. We just build a custom visitor callback pipeline that includes a
database visitor but not a dumper.
All the hackery around printers etc goes away. After this patch, we could
probably even delete the entire CVTypeDumper class since really all it is
at this point is a thin wrapper that hides the details of how to build a
useful visitation pipeline. It's not a priority though, so CVTypeDumper
remains for now.
After this patch we will be able to easily plug in a different style of
type dumper by only implementing the proper visitation methods to dump
one-line output and then sticking it on the pipeline.
Differential Revision: https://reviews.llvm.org/D28524
llvm-svn: 291724
2017-01-12 07:24:22 +08:00
|
|
|
TypeDumpVisitor.cpp
|
2016-05-14 08:02:53 +08:00
|
|
|
TypeRecord.cpp
|
2016-11-03 01:05:19 +08:00
|
|
|
TypeRecordMapping.cpp
|
2016-11-09 06:24:53 +08:00
|
|
|
TypeSerializer.cpp
|
2016-05-14 08:02:53 +08:00
|
|
|
TypeStreamMerger.cpp
|
2015-12-25 02:51:35 +08:00
|
|
|
|
|
|
|
|
ADDITIONAL_HEADER_DIRS
|
|
|
|
|
${LLVM_MAIN_INCLUDE_DIR}/llvm/DebugInfo/CodeView
|
LLVM CodeView library
Summary: This diff is the initial implementation of the LLVM CodeView library. There is much more work to be done, namely a CodeView dumper and tests. This patch should help others make progress on the LLVM->CodeView debug info emission while I continue with the implementation of the dumper and tests.
This library implements support for emitting debug info in the CodeView format. This phase of the implementation only includes support for CodeView type records. Clients that need to emit type records will use a class derived from TypeTableBuilder. TypeTableBuilder provides member functions for writing each kind of type record; each of these functions eventually calls the writeRecord virtual function to emit the actual bits of the record. Derived classes override writeRecord to implement the folding of duplicate records and the actual emission to the appropriate destination. LLVMCodeView provides MemoryTypeTableBuilder, which creates the table in memory. In the future, other classes derived from TypeTableBuilder will write to other destinations, such as the type stream in a PDB.
The rest of the types in LLVMCodeView define the actual CodeView type records and all of the supporting enums and other types used in the type records. The TypeIndex class is of particular interest, because it is used by clients as a handle to a type in the type table.
The library provides a relatively low-level interface based on the actual on-disk format of CodeView. For example, type records refer to other type records by TypeIndex, rather than by an actual pointer to the referent record. This allows clients to emit type records one at a time, rather than having to keep the entire transitive closure of type records in memory until everything has been emitted. At some point, having a higher-level interface layered on top of this one may be useful for debuggers and other tools that want a more holistic view of the debug info. The lower-level interface should be sufficient for compilers and linkers to do the debug info manipulation that they need to do efficiently.
Reviewers: rnk, majnemer
Subscribers: silvas, rnk, jevinskie, llvm-commits
Differential Revision: http://reviews.llvm.org/D14961
llvm-svn: 256385
2015-12-25 02:12:38 +08:00
|
|
|
)
|