[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
|
|
|
//===-- SymbolFilePDB.cpp -------------------------------------------------===//
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "SymbolFilePDB.h"
|
|
|
|
|
|
2018-11-06 08:02:55 +00:00
|
|
|
#include "PDBASTParser.h"
|
|
|
|
|
#include "PDBLocationToDWARFExpression.h"
|
|
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
#include "clang/Lex/Lexer.h"
|
|
|
|
|
|
[lldb] Move clang-based files out of Symbol
Summary:
This change represents the move of ClangASTImporter, ClangASTMetadata,
ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and
TypeSystemClang from lldbSource to lldbPluginExpressionParserClang.h
This explicitly removes knowledge of clang internals from lldbSymbol,
moving towards a more generic core implementation of lldb.
Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafik
Subscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73661
2020-01-29 11:59:28 -08:00
|
|
|
#include "Plugins/TypeSystem/Clang/TypeSystemClang.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "lldb/Core/Module.h"
|
|
|
|
|
#include "lldb/Core/PluginManager.h"
|
|
|
|
|
#include "lldb/Symbol/CompileUnit.h"
|
|
|
|
|
#include "lldb/Symbol/LineTable.h"
|
|
|
|
|
#include "lldb/Symbol/ObjectFile.h"
|
|
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
2018-01-13 06:58:18 +00:00
|
|
|
#include "lldb/Symbol/SymbolVendor.h"
|
2018-01-23 20:35:19 +00:00
|
|
|
#include "lldb/Symbol/TypeList.h"
|
2018-03-22 19:26:33 +00:00
|
|
|
#include "lldb/Symbol/TypeMap.h"
|
2018-05-23 01:52:42 +00:00
|
|
|
#include "lldb/Symbol/Variable.h"
|
2022-02-03 13:26:10 +01:00
|
|
|
#include "lldb/Utility/LLDBLog.h"
|
2019-07-30 22:12:34 +00:00
|
|
|
#include "lldb/Utility/Log.h"
|
2017-12-22 05:26:50 +00:00
|
|
|
#include "lldb/Utility/RegularExpression.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
2022-02-20 00:03:20 +01:00
|
|
|
#include "llvm/DebugInfo/PDB/ConcreteSymbolEnumerator.h"
|
2016-05-09 11:07:43 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/GenericError.h"
|
2017-12-22 00:04:36 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/IPDBDataStream.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/IPDBEnumChildren.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/IPDBLineNumber.h"
|
2018-03-22 19:26:33 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/IPDBSectionContrib.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/IPDBSourceFile.h"
|
2017-12-22 00:04:36 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/IPDBTable.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbol.h"
|
2018-02-09 05:31:28 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolBlock.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolCompiland.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolCompilandDetails.h"
|
2017-12-22 00:04:36 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolData.h"
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolExe.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolFunc.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugEnd.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolFuncDebugStart.h"
|
2018-02-09 05:31:28 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolPublicSymbol.h"
|
2022-02-20 00:03:20 +01:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolTypeBuiltin.h"
|
2016-04-15 00:21:26 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolTypeEnum.h"
|
2022-02-20 00:03:20 +01:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolTypeFunctionSig.h"
|
2016-04-15 00:21:26 +00:00
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolTypeTypedef.h"
|
|
|
|
|
#include "llvm/DebugInfo/PDB/PDBSymbolTypeUDT.h"
|
|
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "Plugins/Language/CPlusPlus/CPlusPlusLanguage.h"
|
2018-11-06 08:02:55 +00:00
|
|
|
#include "Plugins/Language/CPlusPlus/MSVCUndecoratedNameParser.h"
|
2018-10-12 19:47:13 +00:00
|
|
|
#include "Plugins/SymbolFile/NativePDB/SymbolFileNativePDB.h"
|
2016-04-15 00:21:26 +00:00
|
|
|
|
2021-09-21 13:02:52 -04:00
|
|
|
#if defined(_WIN32)
|
2022-04-07 12:11:52 +03:00
|
|
|
#include "llvm/Config/llvm-config.h"
|
2023-01-07 13:43:00 -08:00
|
|
|
#include <optional>
|
2021-09-21 13:02:52 -04:00
|
|
|
#endif
|
|
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
using namespace lldb;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
using namespace lldb_private;
|
2016-05-04 20:33:53 +00:00
|
|
|
using namespace llvm::pdb;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
2020-02-14 09:46:02 -08:00
|
|
|
LLDB_PLUGIN_DEFINE(SymbolFilePDB)
|
2020-02-07 14:58:18 -08:00
|
|
|
|
2019-11-15 10:13:16 -08:00
|
|
|
char SymbolFilePDB::ID;
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
namespace {
|
2016-05-04 20:33:53 +00:00
|
|
|
lldb::LanguageType TranslateLanguage(PDB_Lang lang) {
|
|
|
|
|
switch (lang) {
|
|
|
|
|
case PDB_Lang::Cpp:
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return lldb::LanguageType::eLanguageTypeC_plus_plus;
|
2016-05-04 20:33:53 +00:00
|
|
|
case PDB_Lang::C:
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return lldb::LanguageType::eLanguageTypeC;
|
2019-03-11 23:30:58 +00:00
|
|
|
case PDB_Lang::Swift:
|
|
|
|
|
return lldb::LanguageType::eLanguageTypeSwift;
|
2022-02-16 09:53:00 +00:00
|
|
|
case PDB_Lang::Rust:
|
|
|
|
|
return lldb::LanguageType::eLanguageTypeRust;
|
2023-03-17 17:08:20 +01:00
|
|
|
case PDB_Lang::ObjC:
|
|
|
|
|
return lldb::LanguageType::eLanguageTypeObjC;
|
|
|
|
|
case PDB_Lang::ObjCpp:
|
|
|
|
|
return lldb::LanguageType::eLanguageTypeObjC_plus_plus;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
default:
|
|
|
|
|
return lldb::LanguageType::eLanguageTypeUnknown;
|
2016-03-10 00:06:26 +00:00
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool ShouldAddLine(uint32_t requested_line, uint32_t actual_line,
|
|
|
|
|
uint32_t addr_length) {
|
|
|
|
|
return ((requested_line == 0 || actual_line == requested_line) &&
|
|
|
|
|
addr_length > 0);
|
|
|
|
|
}
|
2018-03-22 03:44:51 +00:00
|
|
|
} // namespace
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
2018-10-12 19:47:13 +00:00
|
|
|
static bool ShouldUseNativeReader() {
|
2018-12-12 18:14:27 +00:00
|
|
|
#if defined(_WIN32)
|
2021-09-21 13:02:52 -04:00
|
|
|
#if LLVM_ENABLE_DIA_SDK
|
2018-10-12 19:47:13 +00:00
|
|
|
llvm::StringRef use_native = ::getenv("LLDB_USE_NATIVE_PDB_READER");
|
2021-09-21 13:02:52 -04:00
|
|
|
if (!use_native.equals_insensitive("on") &&
|
|
|
|
|
!use_native.equals_insensitive("yes") &&
|
|
|
|
|
!use_native.equals_insensitive("1") &&
|
|
|
|
|
!use_native.equals_insensitive("true"))
|
|
|
|
|
return false;
|
|
|
|
|
#endif
|
2018-12-12 18:14:27 +00:00
|
|
|
#endif
|
2021-09-21 13:02:52 -04:00
|
|
|
return true;
|
2018-10-12 19:47:13 +00:00
|
|
|
}
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
void SymbolFilePDB::Initialize() {
|
2018-10-12 19:47:13 +00:00
|
|
|
if (ShouldUseNativeReader()) {
|
|
|
|
|
npdb::SymbolFileNativePDB::Initialize();
|
|
|
|
|
} else {
|
|
|
|
|
PluginManager::RegisterPlugin(GetPluginNameStatic(),
|
|
|
|
|
GetPluginDescriptionStatic(), CreateInstance,
|
|
|
|
|
DebuggerInitialize);
|
|
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SymbolFilePDB::Terminate() {
|
2018-10-12 19:47:13 +00:00
|
|
|
if (ShouldUseNativeReader()) {
|
|
|
|
|
npdb::SymbolFileNativePDB::Terminate();
|
|
|
|
|
} else {
|
|
|
|
|
PluginManager::UnregisterPlugin(CreateInstance);
|
|
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SymbolFilePDB::DebuggerInitialize(lldb_private::Debugger &debugger) {}
|
|
|
|
|
|
2021-10-21 20:13:45 +02:00
|
|
|
llvm::StringRef SymbolFilePDB::GetPluginDescriptionStatic() {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return "Microsoft PDB debug symbol file reader.";
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb_private::SymbolFile *
|
2019-07-31 08:25:25 +00:00
|
|
|
SymbolFilePDB::CreateInstance(ObjectFileSP objfile_sp) {
|
|
|
|
|
return new SymbolFilePDB(std::move(objfile_sp));
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-31 08:25:25 +00:00
|
|
|
SymbolFilePDB::SymbolFilePDB(lldb::ObjectFileSP objfile_sp)
|
2022-04-20 07:30:53 -07:00
|
|
|
: SymbolFileCommon(std::move(objfile_sp)), m_session_up(), m_global_scope_up() {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2021-07-02 11:27:37 -07:00
|
|
|
SymbolFilePDB::~SymbolFilePDB() = default;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
uint32_t SymbolFilePDB::CalculateAbilities() {
|
2017-12-22 00:04:36 +00:00
|
|
|
uint32_t abilities = 0;
|
2019-07-31 08:25:25 +00:00
|
|
|
if (!m_objfile_sp)
|
2017-12-22 00:04:36 +00:00
|
|
|
return 0;
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!m_session_up) {
|
|
|
|
|
// Lazily load and match the PDB file, but only do this once.
|
2019-07-31 08:25:25 +00:00
|
|
|
std::string exePath = m_objfile_sp->GetFileSpec().GetPath();
|
2016-05-04 20:33:53 +00:00
|
|
|
auto error = loadDataForEXE(PDB_ReaderType::DIA, llvm::StringRef(exePath),
|
|
|
|
|
m_session_up);
|
2016-05-06 21:35:47 +00:00
|
|
|
if (error) {
|
2016-05-13 18:26:30 +00:00
|
|
|
llvm::consumeError(std::move(error));
|
2019-07-31 08:25:25 +00:00
|
|
|
auto module_sp = m_objfile_sp->GetModule();
|
2017-12-22 00:04:36 +00:00
|
|
|
if (!module_sp)
|
|
|
|
|
return 0;
|
|
|
|
|
// See if any symbol file is specified through `--symfile` option.
|
|
|
|
|
FileSpec symfile = module_sp->GetSymbolFileFileSpec();
|
|
|
|
|
if (!symfile)
|
|
|
|
|
return 0;
|
|
|
|
|
error = loadDataForPDB(PDB_ReaderType::DIA,
|
2018-03-22 03:44:51 +00:00
|
|
|
llvm::StringRef(symfile.GetPath()), m_session_up);
|
2017-12-22 00:04:36 +00:00
|
|
|
if (error) {
|
|
|
|
|
llvm::consumeError(std::move(error));
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-03-22 19:21:34 +00:00
|
|
|
if (!m_session_up)
|
2017-12-22 00:04:36 +00:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
auto enum_tables_up = m_session_up->getEnumTables();
|
|
|
|
|
if (!enum_tables_up)
|
|
|
|
|
return 0;
|
|
|
|
|
while (auto table_up = enum_tables_up->getNext()) {
|
|
|
|
|
if (table_up->getItemCount() == 0)
|
|
|
|
|
continue;
|
|
|
|
|
auto type = table_up->getTableType();
|
|
|
|
|
switch (type) {
|
|
|
|
|
case PDB_TableType::Symbols:
|
|
|
|
|
// This table represents a store of symbols with types listed in
|
|
|
|
|
// PDBSym_Type
|
2018-03-22 03:44:51 +00:00
|
|
|
abilities |= (CompileUnits | Functions | Blocks | GlobalVariables |
|
|
|
|
|
LocalVariables | VariableTypes);
|
2017-12-22 00:04:36 +00:00
|
|
|
break;
|
|
|
|
|
case PDB_TableType::LineNumbers:
|
|
|
|
|
abilities |= LineTables;
|
|
|
|
|
break;
|
2018-03-22 03:44:51 +00:00
|
|
|
default:
|
|
|
|
|
break;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2017-12-22 00:04:36 +00:00
|
|
|
return abilities;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SymbolFilePDB::InitializeObject() {
|
2019-07-31 08:25:25 +00:00
|
|
|
lldb::addr_t obj_load_address =
|
|
|
|
|
m_objfile_sp->GetBaseAddress().GetFileAddress();
|
2018-03-22 03:44:51 +00:00
|
|
|
lldbassert(obj_load_address && obj_load_address != LLDB_INVALID_ADDRESS);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
m_session_up->setLoadAddress(obj_load_address);
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!m_global_scope_up)
|
|
|
|
|
m_global_scope_up = m_session_up->getGlobalScope();
|
|
|
|
|
lldbassert(m_global_scope_up.get());
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-07-23 09:24:02 +00:00
|
|
|
uint32_t SymbolFilePDB::CalculateNumCompileUnits() {
|
|
|
|
|
auto compilands = m_global_scope_up->findAllChildren<PDBSymbolCompiland>();
|
|
|
|
|
if (!compilands)
|
|
|
|
|
return 0;
|
2018-01-13 06:58:18 +00:00
|
|
|
|
2019-07-23 09:24:02 +00:00
|
|
|
// The linker could link *.dll (compiland language = LINK), or import
|
|
|
|
|
// *.dll. For example, a compiland with name `Import:KERNEL32.dll` could be
|
|
|
|
|
// found as a child of the global scope (PDB executable). Usually, such
|
|
|
|
|
// compilands contain `thunk` symbols in which we are not interested for
|
|
|
|
|
// now. However we still count them in the compiland list. If we perform
|
|
|
|
|
// any compiland related activity, like finding symbols through
|
|
|
|
|
// llvm::pdb::IPDBSession methods, such compilands will all be searched
|
|
|
|
|
// automatically no matter whether we include them or not.
|
|
|
|
|
uint32_t compile_unit_count = compilands->getChildCount();
|
|
|
|
|
|
|
|
|
|
// The linker can inject an additional "dummy" compilation unit into the
|
|
|
|
|
// PDB. Ignore this special compile unit for our purposes, if it is there.
|
|
|
|
|
// It is always the last one.
|
|
|
|
|
auto last_compiland_up = compilands->getChildAtIndex(compile_unit_count - 1);
|
|
|
|
|
lldbassert(last_compiland_up.get());
|
|
|
|
|
std::string name = last_compiland_up->getName();
|
|
|
|
|
if (name == "* Linker *")
|
|
|
|
|
--compile_unit_count;
|
|
|
|
|
return compile_unit_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
void SymbolFilePDB::GetCompileUnitIndex(
|
2018-03-22 03:44:51 +00:00
|
|
|
const llvm::pdb::PDBSymbolCompiland &pdb_compiland, uint32_t &index) {
|
2018-01-13 06:58:18 +00:00
|
|
|
auto results_up = m_global_scope_up->findAllChildren<PDBSymbolCompiland>();
|
|
|
|
|
if (!results_up)
|
|
|
|
|
return;
|
2018-03-19 21:14:19 +00:00
|
|
|
auto uid = pdb_compiland.getSymIndexId();
|
2018-01-22 06:56:09 +00:00
|
|
|
for (uint32_t cu_idx = 0; cu_idx < GetNumCompileUnits(); ++cu_idx) {
|
2018-01-13 06:58:18 +00:00
|
|
|
auto compiland_up = results_up->getChildAtIndex(cu_idx);
|
|
|
|
|
if (!compiland_up)
|
|
|
|
|
continue;
|
|
|
|
|
if (compiland_up->getSymIndexId() == uid) {
|
|
|
|
|
index = cu_idx;
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
index = UINT32_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
std::unique_ptr<llvm::pdb::PDBSymbolCompiland>
|
|
|
|
|
SymbolFilePDB::GetPDBCompilandByUID(uint32_t uid) {
|
|
|
|
|
return m_session_up->getConcreteSymbolById<PDBSymbolCompiland>(uid);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb::CompUnitSP SymbolFilePDB::ParseCompileUnitAtIndex(uint32_t index) {
|
|
|
|
|
if (index >= GetNumCompileUnits())
|
|
|
|
|
return CompUnitSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
// Assuming we always retrieve same compilands listed in same order through
|
|
|
|
|
// `PDBSymbolExe::findAllChildren` method, otherwise using `index` to get a
|
|
|
|
|
// compile unit makes no sense.
|
|
|
|
|
auto results = m_global_scope_up->findAllChildren<PDBSymbolCompiland>();
|
|
|
|
|
if (!results)
|
|
|
|
|
return CompUnitSP();
|
|
|
|
|
auto compiland_up = results->getChildAtIndex(index);
|
|
|
|
|
if (!compiland_up)
|
|
|
|
|
return CompUnitSP();
|
|
|
|
|
return ParseCompileUnitForUID(compiland_up->getSymIndexId(), index);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
lldb::LanguageType SymbolFilePDB::ParseLanguage(CompileUnit &comp_unit) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2019-01-11 18:03:20 +00:00
|
|
|
auto compiland_up = GetPDBCompilandByUID(comp_unit.GetID());
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!compiland_up)
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return lldb::eLanguageTypeUnknown;
|
2018-01-13 06:58:18 +00:00
|
|
|
auto details = compiland_up->findOneChild<PDBSymbolCompilandDetails>();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!details)
|
|
|
|
|
return lldb::eLanguageTypeUnknown;
|
|
|
|
|
return TranslateLanguage(details->getLanguage());
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
lldb_private::Function *
|
|
|
|
|
SymbolFilePDB::ParseCompileUnitFunctionForPDBFunc(const PDBSymbolFunc &pdb_func,
|
|
|
|
|
CompileUnit &comp_unit) {
|
|
|
|
|
if (FunctionSP result = comp_unit.FindFunctionByUID(pdb_func.getSymIndexId()))
|
2018-12-03 13:31:13 +00:00
|
|
|
return result.get();
|
|
|
|
|
|
2018-03-19 21:14:19 +00:00
|
|
|
auto file_vm_addr = pdb_func.getVirtualAddress();
|
2018-03-22 19:26:33 +00:00
|
|
|
if (file_vm_addr == LLDB_INVALID_ADDRESS || file_vm_addr == 0)
|
2018-02-09 05:31:28 +00:00
|
|
|
return nullptr;
|
|
|
|
|
|
2018-03-19 21:14:19 +00:00
|
|
|
auto func_length = pdb_func.getLength();
|
2018-03-22 03:44:51 +00:00
|
|
|
AddressRange func_range =
|
2019-01-11 18:03:20 +00:00
|
|
|
AddressRange(file_vm_addr, func_length,
|
|
|
|
|
GetObjectFile()->GetModule()->GetSectionList());
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!func_range.GetBaseAddress().IsValid())
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
lldb_private::Type *func_type = ResolveTypeUID(pdb_func.getSymIndexId());
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!func_type)
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
2018-03-19 21:14:19 +00:00
|
|
|
user_id_t func_type_uid = pdb_func.getSignatureId();
|
2018-03-07 03:16:50 +00:00
|
|
|
|
2018-02-09 05:31:28 +00:00
|
|
|
Mangled mangled = GetMangledForPDBFunc(pdb_func);
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
FunctionSP func_sp =
|
2019-01-11 18:03:20 +00:00
|
|
|
std::make_shared<Function>(&comp_unit, pdb_func.getSymIndexId(),
|
2018-03-22 03:44:51 +00:00
|
|
|
func_type_uid, mangled, func_type, func_range);
|
2018-02-09 05:31:28 +00:00
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
comp_unit.AddFunction(func_sp);
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
|
2019-03-27 01:24:03 +00:00
|
|
|
LanguageType lang = ParseLanguage(comp_unit);
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err = GetTypeSystemForLanguage(lang);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to parse PDBFunc: {0}");
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
return nullptr;
|
2019-07-30 22:12:34 +00:00
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_type_system =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
if (!clang_type_system)
|
|
|
|
|
return nullptr;
|
|
|
|
|
clang_type_system->GetPDBParser()->GetDeclForSymbol(pdb_func);
|
|
|
|
|
|
2018-02-09 05:31:28 +00:00
|
|
|
return func_sp.get();
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
size_t SymbolFilePDB::ParseFunctions(CompileUnit &comp_unit) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-02-09 05:31:28 +00:00
|
|
|
size_t func_added = 0;
|
2019-01-11 18:03:20 +00:00
|
|
|
auto compiland_up = GetPDBCompilandByUID(comp_unit.GetID());
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!compiland_up)
|
|
|
|
|
return 0;
|
|
|
|
|
auto results_up = compiland_up->findAllChildren<PDBSymbolFunc>();
|
|
|
|
|
if (!results_up)
|
|
|
|
|
return 0;
|
|
|
|
|
while (auto pdb_func_up = results_up->getNext()) {
|
2019-01-11 18:03:20 +00:00
|
|
|
auto func_sp = comp_unit.FindFunctionByUID(pdb_func_up->getSymIndexId());
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!func_sp) {
|
2019-01-11 18:03:20 +00:00
|
|
|
if (ParseCompileUnitFunctionForPDBFunc(*pdb_func_up, comp_unit))
|
2018-02-09 05:31:28 +00:00
|
|
|
++func_added;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return func_added;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
bool SymbolFilePDB::ParseLineTable(CompileUnit &comp_unit) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2019-01-11 18:03:20 +00:00
|
|
|
if (comp_unit.GetLineTable())
|
2018-01-13 06:58:18 +00:00
|
|
|
return true;
|
2019-01-11 18:03:20 +00:00
|
|
|
return ParseCompileUnitLineTable(comp_unit, 0);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
bool SymbolFilePDB::ParseDebugMacros(CompileUnit &comp_unit) {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// PDB doesn't contain information about macros
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
bool SymbolFilePDB::ParseSupportFiles(
|
|
|
|
|
CompileUnit &comp_unit, lldb_private::FileSpecList &support_files) {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
|
|
|
|
// In theory this is unnecessary work for us, because all of this information
|
2017-01-27 21:42:28 +00:00
|
|
|
// is easily (and quickly) accessible from DebugInfoPDB, so caching it a
|
|
|
|
|
// second time seems like a waste. Unfortunately, there's no good way around
|
|
|
|
|
// this short of a moderate refactor since SymbolVendor depends on being able
|
|
|
|
|
// to cache this list.
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2019-01-11 18:03:20 +00:00
|
|
|
auto compiland_up = GetPDBCompilandByUID(comp_unit.GetID());
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!compiland_up)
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return false;
|
2018-01-13 06:58:18 +00:00
|
|
|
auto files = m_session_up->getSourceFilesForCompiland(*compiland_up);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!files || files->getChildCount() == 0)
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
while (auto file = files->getNext()) {
|
2018-11-01 21:05:36 +00:00
|
|
|
FileSpec spec(file->getFileName(), FileSpec::Style::windows);
|
2018-01-13 06:58:18 +00:00
|
|
|
support_files.AppendIfUnique(spec);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2018-06-28 10:03:42 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SymbolFilePDB::ParseImportedModules(
|
|
|
|
|
const lldb_private::SymbolContext &sc,
|
2019-02-13 18:10:41 +00:00
|
|
|
std::vector<SourceModule> &imported_modules) {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// PDB does not yet support module debug info
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
static size_t ParseFunctionBlocksForPDBSymbol(
|
2019-01-14 22:40:41 +00:00
|
|
|
uint64_t func_file_vm_addr, const llvm::pdb::PDBSymbol *pdb_symbol,
|
|
|
|
|
lldb_private::Block *parent_block, bool is_top_parent) {
|
2018-02-09 05:31:28 +00:00
|
|
|
assert(pdb_symbol && parent_block);
|
|
|
|
|
|
|
|
|
|
size_t num_added = 0;
|
|
|
|
|
switch (pdb_symbol->getSymTag()) {
|
|
|
|
|
case PDB_SymType::Block:
|
|
|
|
|
case PDB_SymType::Function: {
|
|
|
|
|
Block *block = nullptr;
|
|
|
|
|
auto &raw_sym = pdb_symbol->getRawSymbol();
|
|
|
|
|
if (auto *pdb_func = llvm::dyn_cast<PDBSymbolFunc>(pdb_symbol)) {
|
|
|
|
|
if (pdb_func->hasNoInlineAttribute())
|
|
|
|
|
break;
|
|
|
|
|
if (is_top_parent)
|
|
|
|
|
block = parent_block;
|
|
|
|
|
else
|
|
|
|
|
break;
|
2021-12-24 21:22:27 -08:00
|
|
|
} else if (llvm::isa<PDBSymbolBlock>(pdb_symbol)) {
|
2018-02-09 05:31:28 +00:00
|
|
|
auto uid = pdb_symbol->getSymIndexId();
|
|
|
|
|
if (parent_block->FindBlockByID(uid))
|
|
|
|
|
break;
|
|
|
|
|
if (raw_sym.getVirtualAddress() < func_file_vm_addr)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
auto block_sp = std::make_shared<Block>(pdb_symbol->getSymIndexId());
|
|
|
|
|
parent_block->AddChild(block_sp);
|
|
|
|
|
block = block_sp.get();
|
|
|
|
|
} else
|
|
|
|
|
llvm_unreachable("Unexpected PDB symbol!");
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
block->AddRange(Block::Range(
|
|
|
|
|
raw_sym.getVirtualAddress() - func_file_vm_addr, raw_sym.getLength()));
|
2018-02-09 05:31:28 +00:00
|
|
|
block->FinalizeRanges();
|
|
|
|
|
++num_added;
|
|
|
|
|
|
|
|
|
|
auto results_up = pdb_symbol->findAllChildren();
|
|
|
|
|
if (!results_up)
|
|
|
|
|
break;
|
|
|
|
|
while (auto symbol_up = results_up->getNext()) {
|
2018-03-22 03:44:51 +00:00
|
|
|
num_added += ParseFunctionBlocksForPDBSymbol(
|
2019-01-14 22:40:41 +00:00
|
|
|
func_file_vm_addr, symbol_up.get(), block, false);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
} break;
|
2018-03-22 03:44:51 +00:00
|
|
|
default:
|
|
|
|
|
break;
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
return num_added;
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-14 22:40:41 +00:00
|
|
|
size_t SymbolFilePDB::ParseBlocksRecursive(Function &func) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-02-09 05:31:28 +00:00
|
|
|
size_t num_added = 0;
|
2019-01-14 22:40:41 +00:00
|
|
|
auto uid = func.GetID();
|
2018-02-09 05:31:28 +00:00
|
|
|
auto pdb_func_up = m_session_up->getConcreteSymbolById<PDBSymbolFunc>(uid);
|
|
|
|
|
if (!pdb_func_up)
|
|
|
|
|
return 0;
|
2019-01-14 22:40:41 +00:00
|
|
|
Block &parent_block = func.GetBlock(false);
|
|
|
|
|
num_added = ParseFunctionBlocksForPDBSymbol(
|
|
|
|
|
pdb_func_up->getVirtualAddress(), pdb_func_up.get(), &parent_block, true);
|
2018-02-09 05:31:28 +00:00
|
|
|
return num_added;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
size_t SymbolFilePDB::ParseTypes(CompileUnit &comp_unit) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-01-23 20:35:19 +00:00
|
|
|
|
2018-03-14 04:05:27 +00:00
|
|
|
size_t num_added = 0;
|
2019-01-10 20:57:50 +00:00
|
|
|
auto compiland = GetPDBCompilandByUID(comp_unit.GetID());
|
2018-03-14 04:05:27 +00:00
|
|
|
if (!compiland)
|
|
|
|
|
return 0;
|
2018-01-23 20:35:19 +00:00
|
|
|
|
2018-03-14 04:05:27 +00:00
|
|
|
auto ParseTypesByTagFn = [&num_added, this](const PDBSymbol &raw_sym) {
|
|
|
|
|
std::unique_ptr<IPDBEnumSymbols> results;
|
2018-03-22 03:44:51 +00:00
|
|
|
PDB_SymType tags_to_search[] = {PDB_SymType::Enum, PDB_SymType::Typedef,
|
|
|
|
|
PDB_SymType::UDT};
|
2018-03-14 04:05:27 +00:00
|
|
|
for (auto tag : tags_to_search) {
|
|
|
|
|
results = raw_sym.findAllChildren(tag);
|
|
|
|
|
if (!results || results->getChildCount() == 0)
|
|
|
|
|
continue;
|
|
|
|
|
while (auto symbol = results->getNext()) {
|
|
|
|
|
switch (symbol->getSymTag()) {
|
|
|
|
|
case PDB_SymType::Enum:
|
|
|
|
|
case PDB_SymType::UDT:
|
|
|
|
|
case PDB_SymType::Typedef:
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// This should cause the type to get cached and stored in the `m_types`
|
|
|
|
|
// lookup.
|
[PDB] Parse UDT symbols and pointers to members (combined patch)
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
2018-08-14 07:57:44 +00:00
|
|
|
if (auto type = ResolveTypeUID(symbol->getSymIndexId())) {
|
|
|
|
|
// Resolve the type completely to avoid a completion
|
|
|
|
|
// (and so a list change, which causes an iterators invalidation)
|
|
|
|
|
// during a TypeList dumping
|
|
|
|
|
type->GetFullCompilerType();
|
|
|
|
|
++num_added;
|
|
|
|
|
}
|
2018-03-14 04:05:27 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
2018-01-23 20:35:19 +00:00
|
|
|
|
2019-01-10 20:57:50 +00:00
|
|
|
ParseTypesByTagFn(*compiland);
|
|
|
|
|
|
|
|
|
|
// Also parse global types particularly coming from this compiland.
|
|
|
|
|
// Unfortunately, PDB has no compiland information for each global type. We
|
|
|
|
|
// have to parse them all. But ensure we only do this once.
|
|
|
|
|
static bool parse_all_global_types = false;
|
|
|
|
|
if (!parse_all_global_types) {
|
|
|
|
|
ParseTypesByTagFn(*m_global_scope_up);
|
|
|
|
|
parse_all_global_types = true;
|
2018-01-23 20:35:19 +00:00
|
|
|
}
|
|
|
|
|
return num_added;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
size_t
|
|
|
|
|
SymbolFilePDB::ParseVariablesForContext(const lldb_private::SymbolContext &sc) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-05-23 01:52:42 +00:00
|
|
|
if (!sc.comp_unit)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
size_t num_added = 0;
|
|
|
|
|
if (sc.function) {
|
|
|
|
|
auto pdb_func = m_session_up->getConcreteSymbolById<PDBSymbolFunc>(
|
|
|
|
|
sc.function->GetID());
|
|
|
|
|
if (!pdb_func)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
num_added += ParseVariables(sc, *pdb_func);
|
|
|
|
|
sc.function->GetBlock(false).SetDidParseVariables(true, true);
|
|
|
|
|
} else if (sc.comp_unit) {
|
|
|
|
|
auto compiland = GetPDBCompilandByUID(sc.comp_unit->GetID());
|
|
|
|
|
if (!compiland)
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
if (sc.comp_unit->GetVariableList(false))
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
auto results = m_global_scope_up->findAllChildren<PDBSymbolData>();
|
|
|
|
|
if (results && results->getChildCount()) {
|
|
|
|
|
while (auto result = results->getNext()) {
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
auto cu_id = GetCompilandId(*result);
|
2018-05-23 01:52:42 +00:00
|
|
|
// FIXME: We are not able to determine variable's compile unit.
|
|
|
|
|
if (cu_id == 0)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (cu_id == sc.comp_unit->GetID())
|
|
|
|
|
num_added += ParseVariables(sc, *result);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// FIXME: A `file static` or `global constant` variable appears both in
|
|
|
|
|
// compiland's children and global scope's children with unexpectedly
|
|
|
|
|
// different symbol's Id making it ambiguous.
|
|
|
|
|
|
|
|
|
|
// FIXME: 'local constant', for example, const char var[] = "abc", declared
|
|
|
|
|
// in a function scope, can't be found in PDB.
|
|
|
|
|
|
|
|
|
|
// Parse variables in this compiland.
|
|
|
|
|
num_added += ParseVariables(sc, *compiland);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return num_added;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb_private::Type *SymbolFilePDB::ResolveTypeUID(lldb::user_id_t type_uid) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2016-04-15 00:21:26 +00:00
|
|
|
auto find_result = m_types.find(type_uid);
|
|
|
|
|
if (find_result != m_types.end())
|
|
|
|
|
return find_result->second.get();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
2019-07-30 22:12:34 +00:00
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to ResolveTypeUID: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_type_system =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!clang_type_system)
|
2016-04-15 00:21:26 +00:00
|
|
|
return nullptr;
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
PDBASTParser *pdb = clang_type_system->GetPDBParser();
|
2016-04-15 00:21:26 +00:00
|
|
|
if (!pdb)
|
|
|
|
|
return nullptr;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
|
|
|
|
auto pdb_type = m_session_up->getSymbolById(type_uid);
|
|
|
|
|
if (pdb_type == nullptr)
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
2016-05-04 20:33:53 +00:00
|
|
|
lldb::TypeSP result = pdb->CreateLLDBTypeFromPDBType(*pdb_type);
|
2018-03-22 19:21:34 +00:00
|
|
|
if (result) {
|
2017-12-22 05:26:50 +00:00
|
|
|
m_types.insert(std::make_pair(type_uid, result));
|
2018-01-23 20:35:19 +00:00
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
return result.get();
|
|
|
|
|
}
|
|
|
|
|
|
2023-01-07 14:18:35 -08:00
|
|
|
std::optional<SymbolFile::ArrayInfo> SymbolFilePDB::GetDynamicArrayInfoForUID(
|
2018-11-05 20:49:07 +00:00
|
|
|
lldb::user_id_t type_uid, const lldb_private::ExecutionContext *exe_ctx) {
|
2022-12-04 16:51:25 -08:00
|
|
|
return std::nullopt;
|
2018-11-05 20:49:07 +00:00
|
|
|
}
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
bool SymbolFilePDB::CompleteType(lldb_private::CompilerType &compiler_type) {
|
[PDB] Parse UDT symbols and pointers to members (combined patch)
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
2018-08-14 07:57:44 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(
|
|
|
|
|
GetObjectFile()->GetModule()->GetMutex());
|
|
|
|
|
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to get dynamic array info for UID: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast_ctx =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
2019-07-30 22:12:34 +00:00
|
|
|
|
[PDB] Parse UDT symbols and pointers to members (combined patch)
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
2018-08-14 07:57:44 +00:00
|
|
|
if (!clang_ast_ctx)
|
|
|
|
|
return false;
|
|
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
PDBASTParser *pdb = clang_ast_ctx->GetPDBParser();
|
[PDB] Parse UDT symbols and pointers to members (combined patch)
Summary:
In this patch I've tried to combine the best ideas from D49368 and D49410,
so it implements following:
- Completion of UDTs from a PDB with a filling of a layout info;
- Pointers to members;
- Fixes the bug relating to a virtual base offset reading from `vbtable`.
The offset was treated as an unsigned, but it can be a negative sometimes.
- Support of MSInheritance attribute
Reviewers: asmith, zturner, rnk, labath, clayborg, lldb-commits
Reviewed By: zturner
Subscribers: aleksandr.urakov, stella.stamenova, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D49980
llvm-svn: 339649
2018-08-14 07:57:44 +00:00
|
|
|
if (!pdb)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
return pdb->CompleteTypeFromPDB(compiler_type);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb_private::CompilerDecl SymbolFilePDB::GetDeclForUID(lldb::user_id_t uid) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to get decl for UID: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return CompilerDecl();
|
|
|
|
|
}
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast_ctx =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!clang_ast_ctx)
|
|
|
|
|
return CompilerDecl();
|
|
|
|
|
|
|
|
|
|
PDBASTParser *pdb = clang_ast_ctx->GetPDBParser();
|
|
|
|
|
if (!pdb)
|
|
|
|
|
return CompilerDecl();
|
|
|
|
|
|
|
|
|
|
auto symbol = m_session_up->getSymbolById(uid);
|
|
|
|
|
if (!symbol)
|
|
|
|
|
return CompilerDecl();
|
|
|
|
|
|
|
|
|
|
auto decl = pdb->GetDeclForSymbol(*symbol);
|
|
|
|
|
if (!decl)
|
|
|
|
|
return CompilerDecl();
|
|
|
|
|
|
2020-01-31 09:22:25 +01:00
|
|
|
return clang_ast_ctx->GetCompilerDecl(decl);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb_private::CompilerDeclContext
|
|
|
|
|
SymbolFilePDB::GetDeclContextForUID(lldb::user_id_t uid) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to get DeclContext for UID: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return CompilerDeclContext();
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast_ctx =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!clang_ast_ctx)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
PDBASTParser *pdb = clang_ast_ctx->GetPDBParser();
|
|
|
|
|
if (!pdb)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
auto symbol = m_session_up->getSymbolById(uid);
|
|
|
|
|
if (!symbol)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
auto decl_context = pdb->GetDeclContextForSymbol(*symbol);
|
|
|
|
|
if (!decl_context)
|
|
|
|
|
return GetDeclContextContainingUID(uid);
|
|
|
|
|
|
2019-12-23 09:05:07 +01:00
|
|
|
return clang_ast_ctx->CreateDeclContext(decl_context);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
lldb_private::CompilerDeclContext
|
|
|
|
|
SymbolFilePDB::GetDeclContextContainingUID(lldb::user_id_t uid) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to get DeclContext containing UID: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return CompilerDeclContext();
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast_ctx =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!clang_ast_ctx)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
PDBASTParser *pdb = clang_ast_ctx->GetPDBParser();
|
|
|
|
|
if (!pdb)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
auto symbol = m_session_up->getSymbolById(uid);
|
|
|
|
|
if (!symbol)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
auto decl_context = pdb->GetDeclContextContainingSymbol(*symbol);
|
|
|
|
|
assert(decl_context);
|
|
|
|
|
|
2019-12-23 09:05:07 +01:00
|
|
|
return clang_ast_ctx->CreateDeclContext(decl_context);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SymbolFilePDB::ParseDeclsForContext(
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
lldb_private::CompilerDeclContext decl_ctx) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to parse decls for context: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary:
This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddling
with Clang's ASTContext when I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext so
the ASTContext naming will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684
2020-01-23 10:04:13 +01:00
|
|
|
TypeSystemClang *clang_ast_ctx =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!clang_ast_ctx)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
PDBASTParser *pdb = clang_ast_ctx->GetPDBParser();
|
|
|
|
|
if (!pdb)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
pdb->ParseDeclsForDeclContext(
|
|
|
|
|
static_cast<clang::DeclContext *>(decl_ctx.GetOpaqueDeclContext()));
|
|
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
|
SymbolFilePDB::ResolveSymbolContext(const lldb_private::Address &so_addr,
|
2018-10-25 20:45:19 +00:00
|
|
|
SymbolContextItem resolve_scope,
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
lldb_private::SymbolContext &sc) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-02-09 05:31:28 +00:00
|
|
|
uint32_t resolved_flags = 0;
|
2018-02-09 11:37:01 +00:00
|
|
|
if (resolve_scope & eSymbolContextCompUnit ||
|
|
|
|
|
resolve_scope & eSymbolContextVariable ||
|
|
|
|
|
resolve_scope & eSymbolContextFunction ||
|
|
|
|
|
resolve_scope & eSymbolContextBlock ||
|
2018-02-09 05:31:28 +00:00
|
|
|
resolve_scope & eSymbolContextLineEntry) {
|
|
|
|
|
auto cu_sp = GetCompileUnitContainsAddress(so_addr);
|
|
|
|
|
if (!cu_sp) {
|
2019-07-31 04:41:05 +00:00
|
|
|
if (resolved_flags & eSymbolContextVariable) {
|
2018-02-09 05:31:28 +00:00
|
|
|
// TODO: Resolve variables
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
sc.comp_unit = cu_sp.get();
|
|
|
|
|
resolved_flags |= eSymbolContextCompUnit;
|
|
|
|
|
lldbassert(sc.module_sp == cu_sp->GetModule());
|
2018-06-28 10:03:42 +00:00
|
|
|
}
|
2018-02-09 05:31:28 +00:00
|
|
|
|
2018-08-29 07:26:11 +00:00
|
|
|
if (resolve_scope & eSymbolContextFunction ||
|
|
|
|
|
resolve_scope & eSymbolContextBlock) {
|
2018-06-28 10:03:42 +00:00
|
|
|
addr_t file_vm_addr = so_addr.GetFileAddress();
|
|
|
|
|
auto symbol_up =
|
|
|
|
|
m_session_up->findSymbolByAddress(file_vm_addr, PDB_SymType::Function);
|
|
|
|
|
if (symbol_up) {
|
|
|
|
|
auto *pdb_func = llvm::dyn_cast<PDBSymbolFunc>(symbol_up.get());
|
|
|
|
|
assert(pdb_func);
|
|
|
|
|
auto func_uid = pdb_func->getSymIndexId();
|
|
|
|
|
sc.function = sc.comp_unit->FindFunctionByUID(func_uid).get();
|
|
|
|
|
if (sc.function == nullptr)
|
2019-01-11 18:03:20 +00:00
|
|
|
sc.function =
|
|
|
|
|
ParseCompileUnitFunctionForPDBFunc(*pdb_func, *sc.comp_unit);
|
2018-06-28 10:03:42 +00:00
|
|
|
if (sc.function) {
|
|
|
|
|
resolved_flags |= eSymbolContextFunction;
|
|
|
|
|
if (resolve_scope & eSymbolContextBlock) {
|
2018-08-29 07:26:11 +00:00
|
|
|
auto block_symbol = m_session_up->findSymbolByAddress(
|
|
|
|
|
file_vm_addr, PDB_SymType::Block);
|
|
|
|
|
auto block_id = block_symbol ? block_symbol->getSymIndexId()
|
|
|
|
|
: sc.function->GetID();
|
|
|
|
|
sc.block = sc.function->GetBlock(true).FindBlockByID(block_id);
|
2018-06-28 10:03:42 +00:00
|
|
|
if (sc.block)
|
|
|
|
|
resolved_flags |= eSymbolContextBlock;
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-06-28 10:03:42 +00:00
|
|
|
}
|
2018-02-09 05:31:28 +00:00
|
|
|
|
2018-06-28 10:03:42 +00:00
|
|
|
if (resolve_scope & eSymbolContextLineEntry) {
|
|
|
|
|
if (auto *line_table = sc.comp_unit->GetLineTable()) {
|
|
|
|
|
Address addr(so_addr);
|
|
|
|
|
if (line_table->FindLineEntryByAddress(addr, sc.line_entry))
|
|
|
|
|
resolved_flags |= eSymbolContextLineEntry;
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-06-28 10:03:42 +00:00
|
|
|
|
2018-02-09 05:31:28 +00:00
|
|
|
return resolved_flags;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
uint32_t SymbolFilePDB::ResolveSymbolContext(
|
2021-05-04 23:03:10 +00:00
|
|
|
const lldb_private::SourceLocationSpec &src_location_spec,
|
2018-10-25 20:45:19 +00:00
|
|
|
SymbolContextItem resolve_scope, lldb_private::SymbolContextList &sc_list) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-01-13 06:58:18 +00:00
|
|
|
const size_t old_size = sc_list.GetSize();
|
2021-05-04 23:03:10 +00:00
|
|
|
const FileSpec &file_spec = src_location_spec.GetFileSpec();
|
2022-06-19 09:12:01 -07:00
|
|
|
const uint32_t line = src_location_spec.GetLine().value_or(0);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (resolve_scope & lldb::eSymbolContextCompUnit) {
|
2016-04-15 00:21:26 +00:00
|
|
|
// Locate all compilation units with line numbers referencing the specified
|
2017-01-27 21:42:28 +00:00
|
|
|
// file. For example, if `file_spec` is <vector>, then this should return
|
|
|
|
|
// all source files and header files that reference <vector>, either
|
|
|
|
|
// directly or indirectly.
|
2016-04-15 00:21:26 +00:00
|
|
|
auto compilands = m_session_up->findCompilandsForSourceFile(
|
|
|
|
|
file_spec.GetPath(), PDB_NameSearchFlags::NS_CaseInsensitive);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!compilands)
|
|
|
|
|
return 0;
|
|
|
|
|
|
2017-01-27 21:42:28 +00:00
|
|
|
// For each one, either find its previously parsed data or parse it afresh
|
|
|
|
|
// and add it to the symbol context list.
|
2016-04-15 00:21:26 +00:00
|
|
|
while (auto compiland = compilands->getNext()) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// If we're not checking inlines, then don't add line information for
|
|
|
|
|
// this file unless the FileSpec matches. For inline functions, we don't
|
|
|
|
|
// have to match the FileSpec since they could be defined in headers
|
|
|
|
|
// other than file specified in FileSpec.
|
2021-05-04 23:03:10 +00:00
|
|
|
if (!src_location_spec.GetCheckInlines()) {
|
2018-03-20 00:18:22 +00:00
|
|
|
std::string source_file = compiland->getSourceFileFullPath();
|
2018-01-13 06:58:18 +00:00
|
|
|
if (source_file.empty())
|
|
|
|
|
continue;
|
2018-11-01 21:05:36 +00:00
|
|
|
FileSpec this_spec(source_file, FileSpec::Style::windows);
|
2018-01-13 06:58:18 +00:00
|
|
|
bool need_full_match = !file_spec.GetDirectory().IsEmpty();
|
|
|
|
|
if (FileSpec::Compare(file_spec, this_spec, need_full_match) != 0)
|
2016-04-15 00:21:26 +00:00
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
SymbolContext sc;
|
2018-01-13 06:58:18 +00:00
|
|
|
auto cu = ParseCompileUnitForUID(compiland->getSymIndexId());
|
2018-03-22 19:21:34 +00:00
|
|
|
if (!cu)
|
2018-01-13 06:58:18 +00:00
|
|
|
continue;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
sc.comp_unit = cu.get();
|
2016-04-15 00:21:26 +00:00
|
|
|
sc.module_sp = cu->GetModule();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
// If we were asked to resolve line entries, add all entries to the line
|
2017-01-27 21:42:28 +00:00
|
|
|
// table that match the requested line (or all lines if `line` == 0).
|
2018-02-09 05:31:28 +00:00
|
|
|
if (resolve_scope & (eSymbolContextFunction | eSymbolContextBlock |
|
|
|
|
|
eSymbolContextLineEntry)) {
|
2019-01-11 18:03:20 +00:00
|
|
|
bool has_line_table = ParseCompileUnitLineTable(*sc.comp_unit, line);
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
if ((resolve_scope & eSymbolContextLineEntry) && !has_line_table) {
|
|
|
|
|
// The query asks for line entries, but we can't get them for the
|
2018-04-30 16:49:04 +00:00
|
|
|
// compile unit. This is not normal for `line` = 0. So just assert
|
|
|
|
|
// it.
|
2018-03-07 03:16:50 +00:00
|
|
|
assert(line && "Couldn't get all line entries!\n");
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
// Current compiland does not have the requested line. Search next.
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (resolve_scope & (eSymbolContextFunction | eSymbolContextBlock)) {
|
|
|
|
|
if (!has_line_table)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto *line_table = sc.comp_unit->GetLineTable();
|
|
|
|
|
lldbassert(line_table);
|
|
|
|
|
|
|
|
|
|
uint32_t num_line_entries = line_table->GetSize();
|
|
|
|
|
// Skip the terminal line entry.
|
|
|
|
|
--num_line_entries;
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// If `line `!= 0, see if we can resolve function for each line entry
|
|
|
|
|
// in the line table.
|
2018-02-09 05:31:28 +00:00
|
|
|
for (uint32_t line_idx = 0; line && line_idx < num_line_entries;
|
|
|
|
|
++line_idx) {
|
|
|
|
|
if (!line_table->GetLineEntryAtIndex(line_idx, sc.line_entry))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto file_vm_addr =
|
|
|
|
|
sc.line_entry.range.GetBaseAddress().GetFileAddress();
|
2018-03-22 19:26:33 +00:00
|
|
|
if (file_vm_addr == LLDB_INVALID_ADDRESS || file_vm_addr == 0)
|
2018-02-09 05:31:28 +00:00
|
|
|
continue;
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
auto symbol_up = m_session_up->findSymbolByAddress(
|
|
|
|
|
file_vm_addr, PDB_SymType::Function);
|
2018-02-09 05:31:28 +00:00
|
|
|
if (symbol_up) {
|
|
|
|
|
auto func_uid = symbol_up->getSymIndexId();
|
|
|
|
|
sc.function = sc.comp_unit->FindFunctionByUID(func_uid).get();
|
|
|
|
|
if (sc.function == nullptr) {
|
|
|
|
|
auto pdb_func = llvm::dyn_cast<PDBSymbolFunc>(symbol_up.get());
|
|
|
|
|
assert(pdb_func);
|
2019-01-11 18:03:20 +00:00
|
|
|
sc.function = ParseCompileUnitFunctionForPDBFunc(*pdb_func,
|
|
|
|
|
*sc.comp_unit);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
if (sc.function && (resolve_scope & eSymbolContextBlock)) {
|
|
|
|
|
Block &block = sc.function->GetBlock(true);
|
|
|
|
|
sc.block = block.FindBlockByID(sc.function->GetID());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
sc_list.Append(sc);
|
|
|
|
|
}
|
|
|
|
|
} else if (has_line_table) {
|
|
|
|
|
// We can parse line table for the compile unit. But no query to
|
|
|
|
|
// resolve function or block. We append `sc` to the list anyway.
|
|
|
|
|
sc_list.Append(sc);
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// No query for line entry, function or block. But we have a valid
|
|
|
|
|
// compile unit, append `sc` to the list.
|
|
|
|
|
sc_list.Append(sc);
|
|
|
|
|
}
|
2016-04-15 00:21:26 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2018-01-13 06:58:18 +00:00
|
|
|
return sc_list.GetSize() - old_size;
|
2016-04-15 00:21:26 +00:00
|
|
|
}
|
|
|
|
|
|
2018-05-23 01:52:42 +00:00
|
|
|
std::string SymbolFilePDB::GetMangledForPDBData(const PDBSymbolData &pdb_data) {
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
// Cache public names at first
|
|
|
|
|
if (m_public_names.empty())
|
|
|
|
|
if (auto result_up =
|
|
|
|
|
m_global_scope_up->findAllChildren(PDB_SymType::PublicSymbol))
|
|
|
|
|
while (auto symbol_up = result_up->getNext())
|
|
|
|
|
if (auto addr = symbol_up->getRawSymbol().getVirtualAddress())
|
|
|
|
|
m_public_names[addr] = symbol_up->getRawSymbol().getName();
|
|
|
|
|
|
|
|
|
|
// Look up the name in the cache
|
|
|
|
|
return m_public_names.lookup(pdb_data.getVirtualAddress());
|
2018-05-23 01:52:42 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
VariableSP SymbolFilePDB::ParseVariableForPDBData(
|
|
|
|
|
const lldb_private::SymbolContext &sc,
|
|
|
|
|
const llvm::pdb::PDBSymbolData &pdb_data) {
|
|
|
|
|
VariableSP var_sp;
|
|
|
|
|
uint32_t var_uid = pdb_data.getSymIndexId();
|
|
|
|
|
auto result = m_variables.find(var_uid);
|
|
|
|
|
if (result != m_variables.end())
|
|
|
|
|
return result->second;
|
|
|
|
|
|
|
|
|
|
ValueType scope = eValueTypeInvalid;
|
|
|
|
|
bool is_static_member = false;
|
|
|
|
|
bool is_external = false;
|
|
|
|
|
bool is_artificial = false;
|
|
|
|
|
|
|
|
|
|
switch (pdb_data.getDataKind()) {
|
|
|
|
|
case PDB_DataKind::Global:
|
|
|
|
|
scope = eValueTypeVariableGlobal;
|
|
|
|
|
is_external = true;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::Local:
|
|
|
|
|
scope = eValueTypeVariableLocal;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::FileStatic:
|
|
|
|
|
scope = eValueTypeVariableStatic;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::StaticMember:
|
|
|
|
|
is_static_member = true;
|
|
|
|
|
scope = eValueTypeVariableStatic;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::Member:
|
|
|
|
|
scope = eValueTypeVariableStatic;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::Param:
|
|
|
|
|
scope = eValueTypeVariableArgument;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_DataKind::Constant:
|
|
|
|
|
scope = eValueTypeConstResult;
|
|
|
|
|
break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch (pdb_data.getLocationType()) {
|
|
|
|
|
case PDB_LocType::TLS:
|
|
|
|
|
scope = eValueTypeVariableThreadLocal;
|
|
|
|
|
break;
|
|
|
|
|
case PDB_LocType::RegRel: {
|
|
|
|
|
// It is a `this` pointer.
|
|
|
|
|
if (pdb_data.getDataKind() == PDB_DataKind::ObjectPtr) {
|
|
|
|
|
scope = eValueTypeVariableArgument;
|
|
|
|
|
is_artificial = true;
|
|
|
|
|
}
|
|
|
|
|
} break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Declaration decl;
|
|
|
|
|
if (!is_artificial && !pdb_data.isCompilerGenerated()) {
|
|
|
|
|
if (auto lines = pdb_data.getLineNumbers()) {
|
|
|
|
|
if (auto first_line = lines->getNext()) {
|
|
|
|
|
uint32_t src_file_id = first_line->getSourceFileId();
|
|
|
|
|
auto src_file = m_session_up->getSourceFileById(src_file_id);
|
|
|
|
|
if (src_file) {
|
2018-11-01 21:05:36 +00:00
|
|
|
FileSpec spec(src_file->getFileName());
|
2018-05-23 01:52:42 +00:00
|
|
|
decl.SetFile(spec);
|
|
|
|
|
decl.SetColumn(first_line->getColumnNumber());
|
|
|
|
|
decl.SetLine(first_line->getLineNumber());
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Variable::RangeList ranges;
|
|
|
|
|
SymbolContextScope *context_scope = sc.comp_unit;
|
2019-02-01 10:01:18 +00:00
|
|
|
if (scope == eValueTypeVariableLocal || scope == eValueTypeVariableArgument) {
|
2018-05-23 01:52:42 +00:00
|
|
|
if (sc.function) {
|
2019-02-01 10:01:18 +00:00
|
|
|
Block &function_block = sc.function->GetBlock(true);
|
|
|
|
|
Block *block =
|
|
|
|
|
function_block.FindBlockByID(pdb_data.getLexicalParentId());
|
|
|
|
|
if (!block)
|
|
|
|
|
block = &function_block;
|
|
|
|
|
|
|
|
|
|
context_scope = block;
|
|
|
|
|
|
|
|
|
|
for (size_t i = 0, num_ranges = block->GetNumRanges(); i < num_ranges;
|
|
|
|
|
++i) {
|
|
|
|
|
AddressRange range;
|
|
|
|
|
if (!block->GetRangeAtIndex(i, range))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
ranges.Append(range.GetBaseAddress().GetFileAddress(),
|
|
|
|
|
range.GetByteSize());
|
|
|
|
|
}
|
2018-05-23 01:52:42 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SymbolFileTypeSP type_sp =
|
|
|
|
|
std::make_shared<SymbolFileType>(*this, pdb_data.getTypeId());
|
|
|
|
|
|
|
|
|
|
auto var_name = pdb_data.getName();
|
|
|
|
|
auto mangled = GetMangledForPDBData(pdb_data);
|
|
|
|
|
auto mangled_cstr = mangled.empty() ? nullptr : mangled.c_str();
|
|
|
|
|
|
2018-07-13 10:29:27 +00:00
|
|
|
bool is_constant;
|
2022-07-12 10:30:49 -07:00
|
|
|
ModuleSP module_sp = GetObjectFile()->GetModule();
|
|
|
|
|
DWARFExpressionList location(module_sp,
|
|
|
|
|
ConvertPDBLocationToDWARFExpression(
|
|
|
|
|
module_sp, pdb_data, ranges, is_constant),
|
|
|
|
|
nullptr);
|
2018-05-23 01:52:42 +00:00
|
|
|
|
|
|
|
|
var_sp = std::make_shared<Variable>(
|
|
|
|
|
var_uid, var_name.c_str(), mangled_cstr, type_sp, scope, context_scope,
|
2020-10-13 17:00:32 -07:00
|
|
|
ranges, &decl, location, is_external, is_artificial, is_constant,
|
|
|
|
|
is_static_member);
|
2018-05-23 01:52:42 +00:00
|
|
|
|
|
|
|
|
m_variables.insert(std::make_pair(var_uid, var_sp));
|
|
|
|
|
return var_sp;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
size_t
|
|
|
|
|
SymbolFilePDB::ParseVariables(const lldb_private::SymbolContext &sc,
|
|
|
|
|
const llvm::pdb::PDBSymbol &pdb_symbol,
|
|
|
|
|
lldb_private::VariableList *variable_list) {
|
|
|
|
|
size_t num_added = 0;
|
|
|
|
|
|
|
|
|
|
if (auto pdb_data = llvm::dyn_cast<PDBSymbolData>(&pdb_symbol)) {
|
|
|
|
|
VariableListSP local_variable_list_sp;
|
|
|
|
|
|
|
|
|
|
auto result = m_variables.find(pdb_data->getSymIndexId());
|
|
|
|
|
if (result != m_variables.end()) {
|
|
|
|
|
if (variable_list)
|
|
|
|
|
variable_list->AddVariableIfUnique(result->second);
|
|
|
|
|
} else {
|
|
|
|
|
// Prepare right VariableList for this variable.
|
|
|
|
|
if (auto lexical_parent = pdb_data->getLexicalParent()) {
|
|
|
|
|
switch (lexical_parent->getSymTag()) {
|
|
|
|
|
case PDB_SymType::Exe:
|
|
|
|
|
assert(sc.comp_unit);
|
2022-08-08 11:31:49 -07:00
|
|
|
[[fallthrough]];
|
2018-05-23 01:52:42 +00:00
|
|
|
case PDB_SymType::Compiland: {
|
|
|
|
|
if (sc.comp_unit) {
|
|
|
|
|
local_variable_list_sp = sc.comp_unit->GetVariableList(false);
|
|
|
|
|
if (!local_variable_list_sp) {
|
|
|
|
|
local_variable_list_sp = std::make_shared<VariableList>();
|
|
|
|
|
sc.comp_unit->SetVariableList(local_variable_list_sp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} break;
|
|
|
|
|
case PDB_SymType::Block:
|
|
|
|
|
case PDB_SymType::Function: {
|
|
|
|
|
if (sc.function) {
|
|
|
|
|
Block *block = sc.function->GetBlock(true).FindBlockByID(
|
|
|
|
|
lexical_parent->getSymIndexId());
|
|
|
|
|
if (block) {
|
|
|
|
|
local_variable_list_sp = block->GetBlockVariableList(false);
|
|
|
|
|
if (!local_variable_list_sp) {
|
|
|
|
|
local_variable_list_sp = std::make_shared<VariableList>();
|
|
|
|
|
block->SetVariableList(local_variable_list_sp);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} break;
|
|
|
|
|
default:
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (local_variable_list_sp) {
|
|
|
|
|
if (auto var_sp = ParseVariableForPDBData(sc, *pdb_data)) {
|
|
|
|
|
local_variable_list_sp->AddVariableIfUnique(var_sp);
|
|
|
|
|
if (variable_list)
|
|
|
|
|
variable_list->AddVariableIfUnique(var_sp);
|
|
|
|
|
++num_added;
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
PDBASTParser *ast = GetPDBAstParser();
|
|
|
|
|
if (ast)
|
|
|
|
|
ast->GetDeclForSymbol(*pdb_data);
|
2018-05-23 01:52:42 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (auto results = pdb_symbol.findAllChildren()) {
|
|
|
|
|
while (auto result = results->getNext())
|
|
|
|
|
num_added += ParseVariables(sc, *result, variable_list);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return num_added;
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-17 19:56:40 +00:00
|
|
|
void SymbolFilePDB::FindGlobalVariables(
|
2020-02-17 19:25:52 +01:00
|
|
|
lldb_private::ConstString name, const CompilerDeclContext &parent_decl_ctx,
|
2016-04-15 00:21:26 +00:00
|
|
|
uint32_t max_matches, lldb_private::VariableList &variables) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-05-23 01:52:42 +00:00
|
|
|
if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-05-23 01:52:42 +00:00
|
|
|
if (name.IsEmpty())
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-05-23 01:52:42 +00:00
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
auto results = m_global_scope_up->findAllChildren<PDBSymbolData>();
|
2018-05-23 01:52:42 +00:00
|
|
|
if (!results)
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-05-23 01:52:42 +00:00
|
|
|
|
|
|
|
|
uint32_t matches = 0;
|
|
|
|
|
size_t old_size = variables.GetSize();
|
|
|
|
|
while (auto result = results->getNext()) {
|
|
|
|
|
auto pdb_data = llvm::dyn_cast<PDBSymbolData>(result.get());
|
|
|
|
|
if (max_matches > 0 && matches >= max_matches)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
SymbolContext sc;
|
2019-07-31 08:25:25 +00:00
|
|
|
sc.module_sp = m_objfile_sp->GetModule();
|
2018-05-23 01:52:42 +00:00
|
|
|
lldbassert(sc.module_sp.get());
|
|
|
|
|
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!name.GetStringRef().equals(
|
2018-11-06 08:02:55 +00:00
|
|
|
MSVCUndecoratedNameParser::DropScope(pdb_data->getName())))
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
continue;
|
|
|
|
|
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
sc.comp_unit = ParseCompileUnitForUID(GetCompilandId(*pdb_data)).get();
|
|
|
|
|
// FIXME: We are not able to determine the compile unit.
|
|
|
|
|
if (sc.comp_unit == nullptr)
|
|
|
|
|
continue;
|
|
|
|
|
|
2020-02-17 19:25:52 +01:00
|
|
|
if (parent_decl_ctx.IsValid() &&
|
|
|
|
|
GetDeclContextContainingUID(result->getSymIndexId()) != parent_decl_ctx)
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
continue;
|
|
|
|
|
|
2018-05-23 01:52:42 +00:00
|
|
|
ParseVariables(sc, *pdb_data, &variables);
|
|
|
|
|
matches = variables.GetSize() - old_size;
|
|
|
|
|
}
|
2016-04-15 00:21:26 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-17 19:56:40 +00:00
|
|
|
void SymbolFilePDB::FindGlobalVariables(
|
|
|
|
|
const lldb_private::RegularExpression ®ex, uint32_t max_matches,
|
|
|
|
|
lldb_private::VariableList &variables) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-05-23 01:52:42 +00:00
|
|
|
if (!regex.IsValid())
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-05-23 01:52:42 +00:00
|
|
|
auto results = m_global_scope_up->findAllChildren<PDBSymbolData>();
|
|
|
|
|
if (!results)
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-05-23 01:52:42 +00:00
|
|
|
|
|
|
|
|
uint32_t matches = 0;
|
|
|
|
|
size_t old_size = variables.GetSize();
|
|
|
|
|
while (auto pdb_data = results->getNext()) {
|
|
|
|
|
if (max_matches > 0 && matches >= max_matches)
|
|
|
|
|
break;
|
|
|
|
|
|
|
|
|
|
auto var_name = pdb_data->getName();
|
|
|
|
|
if (var_name.empty())
|
|
|
|
|
continue;
|
|
|
|
|
if (!regex.Execute(var_name))
|
|
|
|
|
continue;
|
|
|
|
|
SymbolContext sc;
|
2019-07-31 08:25:25 +00:00
|
|
|
sc.module_sp = m_objfile_sp->GetModule();
|
2018-05-23 01:52:42 +00:00
|
|
|
lldbassert(sc.module_sp.get());
|
|
|
|
|
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
sc.comp_unit = ParseCompileUnitForUID(GetCompilandId(*pdb_data)).get();
|
2018-05-23 01:52:42 +00:00
|
|
|
// FIXME: We are not able to determine the compile unit.
|
|
|
|
|
if (sc.comp_unit == nullptr)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
ParseVariables(sc, *pdb_data, &variables);
|
|
|
|
|
matches = variables.GetSize() - old_size;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2016-04-15 00:21:26 +00:00
|
|
|
|
2018-03-19 21:14:19 +00:00
|
|
|
bool SymbolFilePDB::ResolveFunction(const llvm::pdb::PDBSymbolFunc &pdb_func,
|
2018-02-09 05:31:28 +00:00
|
|
|
bool include_inlines,
|
|
|
|
|
lldb_private::SymbolContextList &sc_list) {
|
|
|
|
|
lldb_private::SymbolContext sc;
|
2018-03-20 00:34:18 +00:00
|
|
|
sc.comp_unit = ParseCompileUnitForUID(pdb_func.getCompilandId()).get();
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!sc.comp_unit)
|
|
|
|
|
return false;
|
|
|
|
|
sc.module_sp = sc.comp_unit->GetModule();
|
2019-01-11 18:03:20 +00:00
|
|
|
sc.function = ParseCompileUnitFunctionForPDBFunc(pdb_func, *sc.comp_unit);
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!sc.function)
|
|
|
|
|
return false;
|
|
|
|
|
|
|
|
|
|
sc_list.Append(sc);
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SymbolFilePDB::ResolveFunction(uint32_t uid, bool include_inlines,
|
|
|
|
|
lldb_private::SymbolContextList &sc_list) {
|
2018-03-22 03:44:51 +00:00
|
|
|
auto pdb_func_up = m_session_up->getConcreteSymbolById<PDBSymbolFunc>(uid);
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!pdb_func_up && !(include_inlines && pdb_func_up->hasInlineAttribute()))
|
|
|
|
|
return false;
|
2018-03-19 21:14:19 +00:00
|
|
|
return ResolveFunction(*pdb_func_up, include_inlines, sc_list);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void SymbolFilePDB::CacheFunctionNames() {
|
|
|
|
|
if (!m_func_full_names.IsEmpty())
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
std::map<uint64_t, uint32_t> addr_ids;
|
|
|
|
|
|
|
|
|
|
if (auto results_up = m_global_scope_up->findAllChildren<PDBSymbolFunc>()) {
|
|
|
|
|
while (auto pdb_func_up = results_up->getNext()) {
|
2018-03-07 03:16:50 +00:00
|
|
|
if (pdb_func_up->isCompilerGenerated())
|
|
|
|
|
continue;
|
|
|
|
|
|
2018-02-09 05:31:28 +00:00
|
|
|
auto name = pdb_func_up->getName();
|
|
|
|
|
auto demangled_name = pdb_func_up->getUndecoratedName();
|
|
|
|
|
if (name.empty() && demangled_name.empty())
|
|
|
|
|
continue;
|
|
|
|
|
|
2018-03-07 03:16:50 +00:00
|
|
|
auto uid = pdb_func_up->getSymIndexId();
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!demangled_name.empty() && pdb_func_up->getVirtualAddress())
|
|
|
|
|
addr_ids.insert(std::make_pair(pdb_func_up->getVirtualAddress(), uid));
|
|
|
|
|
|
|
|
|
|
if (auto parent = pdb_func_up->getClassParent()) {
|
|
|
|
|
|
|
|
|
|
// PDB have symbols for class/struct methods or static methods in Enum
|
|
|
|
|
// Class. We won't bother to check if the parent is UDT or Enum here.
|
|
|
|
|
m_func_method_names.Append(ConstString(name), uid);
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// To search a method name, like NS::Class:MemberFunc, LLDB searches
|
|
|
|
|
// its base name, i.e. MemberFunc by default. Since PDBSymbolFunc does
|
2020-01-21 15:31:58 -08:00
|
|
|
// not have information of this, we extract base names and cache them
|
2018-04-30 16:49:04 +00:00
|
|
|
// by our own effort.
|
2018-11-06 08:02:55 +00:00
|
|
|
llvm::StringRef basename = MSVCUndecoratedNameParser::DropScope(name);
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!basename.empty())
|
|
|
|
|
m_func_base_names.Append(ConstString(basename), uid);
|
|
|
|
|
else {
|
|
|
|
|
m_func_base_names.Append(ConstString(name), uid);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!demangled_name.empty())
|
|
|
|
|
m_func_full_names.Append(ConstString(demangled_name), uid);
|
|
|
|
|
|
|
|
|
|
} else {
|
|
|
|
|
// Handle not-method symbols.
|
|
|
|
|
|
2018-11-06 08:02:55 +00:00
|
|
|
// The function name might contain namespace, or its lexical scope.
|
|
|
|
|
llvm::StringRef basename = MSVCUndecoratedNameParser::DropScope(name);
|
|
|
|
|
if (!basename.empty())
|
|
|
|
|
m_func_base_names.Append(ConstString(basename), uid);
|
|
|
|
|
else
|
|
|
|
|
m_func_base_names.Append(ConstString(name), uid);
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
if (name == "main") {
|
|
|
|
|
m_func_full_names.Append(ConstString(name), uid);
|
|
|
|
|
|
|
|
|
|
if (!demangled_name.empty() && name != demangled_name) {
|
|
|
|
|
m_func_full_names.Append(ConstString(demangled_name), uid);
|
|
|
|
|
m_func_base_names.Append(ConstString(demangled_name), uid);
|
|
|
|
|
}
|
|
|
|
|
} else if (!demangled_name.empty()) {
|
|
|
|
|
m_func_full_names.Append(ConstString(demangled_name), uid);
|
|
|
|
|
} else {
|
|
|
|
|
m_func_full_names.Append(ConstString(name), uid);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (auto results_up =
|
2018-03-22 03:44:51 +00:00
|
|
|
m_global_scope_up->findAllChildren<PDBSymbolPublicSymbol>()) {
|
2018-02-09 05:31:28 +00:00
|
|
|
while (auto pub_sym_up = results_up->getNext()) {
|
|
|
|
|
if (!pub_sym_up->isFunction())
|
|
|
|
|
continue;
|
|
|
|
|
auto name = pub_sym_up->getName();
|
|
|
|
|
if (name.empty())
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (CPlusPlusLanguage::IsCPPMangledName(name.c_str())) {
|
|
|
|
|
auto vm_addr = pub_sym_up->getVirtualAddress();
|
|
|
|
|
|
|
|
|
|
// PDB public symbol has mangled name for its associated function.
|
|
|
|
|
if (vm_addr && addr_ids.find(vm_addr) != addr_ids.end()) {
|
|
|
|
|
// Cache mangled name.
|
|
|
|
|
m_func_full_names.Append(ConstString(name), addr_ids[vm_addr]);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// Sort them before value searching is working properly
|
|
|
|
|
m_func_full_names.Sort();
|
|
|
|
|
m_func_full_names.SizeToFit();
|
|
|
|
|
m_func_method_names.Sort();
|
|
|
|
|
m_func_method_names.SizeToFit();
|
|
|
|
|
m_func_base_names.Sort();
|
|
|
|
|
m_func_base_names.SizeToFit();
|
|
|
|
|
}
|
|
|
|
|
|
2019-10-17 19:56:40 +00:00
|
|
|
void SymbolFilePDB::FindFunctions(
|
2022-08-04 11:53:28 -07:00
|
|
|
const lldb_private::Module::LookupInfo &lookup_info,
|
2020-02-17 19:25:52 +01:00
|
|
|
const lldb_private::CompilerDeclContext &parent_decl_ctx,
|
2022-08-04 11:53:28 -07:00
|
|
|
bool include_inlines,
|
2016-04-15 00:21:26 +00:00
|
|
|
lldb_private::SymbolContextList &sc_list) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2022-08-04 11:53:28 -07:00
|
|
|
ConstString name = lookup_info.GetLookupName();
|
|
|
|
|
FunctionNameType name_type_mask = lookup_info.GetNameTypeMask();
|
2018-02-09 05:31:28 +00:00
|
|
|
lldbassert((name_type_mask & eFunctionNameTypeAuto) == 0);
|
|
|
|
|
|
2022-08-04 11:53:28 -07:00
|
|
|
if (name_type_mask & eFunctionNameTypeFull)
|
|
|
|
|
name = lookup_info.GetName();
|
|
|
|
|
|
2018-02-09 05:31:28 +00:00
|
|
|
if (name_type_mask == eFunctionNameTypeNone)
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!DeclContextMatchesThisSymbolFile(parent_decl_ctx))
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-02-09 05:31:28 +00:00
|
|
|
if (name.IsEmpty())
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-02-09 05:31:28 +00:00
|
|
|
|
2018-02-09 11:37:01 +00:00
|
|
|
if (name_type_mask & eFunctionNameTypeFull ||
|
|
|
|
|
name_type_mask & eFunctionNameTypeBase ||
|
2018-02-09 05:31:28 +00:00
|
|
|
name_type_mask & eFunctionNameTypeMethod) {
|
|
|
|
|
CacheFunctionNames();
|
|
|
|
|
|
|
|
|
|
std::set<uint32_t> resolved_ids;
|
2018-12-03 13:31:13 +00:00
|
|
|
auto ResolveFn = [this, &name, parent_decl_ctx, include_inlines, &sc_list,
|
|
|
|
|
&resolved_ids](UniqueCStringMap<uint32_t> &Names) {
|
2018-02-09 05:31:28 +00:00
|
|
|
std::vector<uint32_t> ids;
|
2018-12-03 13:31:13 +00:00
|
|
|
if (!Names.GetValues(name, ids))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
for (uint32_t id : ids) {
|
|
|
|
|
if (resolved_ids.find(id) != resolved_ids.end())
|
|
|
|
|
continue;
|
|
|
|
|
|
2020-02-17 19:25:52 +01:00
|
|
|
if (parent_decl_ctx.IsValid() &&
|
|
|
|
|
GetDeclContextContainingUID(id) != parent_decl_ctx)
|
2018-12-03 13:31:13 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
if (ResolveFunction(id, include_inlines, sc_list))
|
|
|
|
|
resolved_ids.insert(id);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
if (name_type_mask & eFunctionNameTypeFull) {
|
|
|
|
|
ResolveFn(m_func_full_names);
|
2018-12-03 13:31:13 +00:00
|
|
|
ResolveFn(m_func_base_names);
|
|
|
|
|
ResolveFn(m_func_method_names);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
2019-10-17 19:56:40 +00:00
|
|
|
if (name_type_mask & eFunctionNameTypeBase)
|
2018-02-09 05:31:28 +00:00
|
|
|
ResolveFn(m_func_base_names);
|
2019-10-17 19:56:40 +00:00
|
|
|
if (name_type_mask & eFunctionNameTypeMethod)
|
2018-02-09 05:31:28 +00:00
|
|
|
ResolveFn(m_func_method_names);
|
|
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-17 19:56:40 +00:00
|
|
|
void SymbolFilePDB::FindFunctions(const lldb_private::RegularExpression ®ex,
|
|
|
|
|
bool include_inlines,
|
|
|
|
|
lldb_private::SymbolContextList &sc_list) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!regex.IsValid())
|
2019-10-17 19:56:40 +00:00
|
|
|
return;
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
CacheFunctionNames();
|
|
|
|
|
|
|
|
|
|
std::set<uint32_t> resolved_ids;
|
2018-03-22 03:44:51 +00:00
|
|
|
auto ResolveFn = [®ex, include_inlines, &sc_list, &resolved_ids,
|
|
|
|
|
this](UniqueCStringMap<uint32_t> &Names) {
|
2018-02-09 05:31:28 +00:00
|
|
|
std::vector<uint32_t> ids;
|
|
|
|
|
if (Names.GetValues(regex, ids)) {
|
|
|
|
|
for (auto id : ids) {
|
|
|
|
|
if (resolved_ids.find(id) == resolved_ids.end())
|
|
|
|
|
if (ResolveFunction(id, include_inlines, sc_list))
|
|
|
|
|
resolved_ids.insert(id);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
ResolveFn(m_func_full_names);
|
|
|
|
|
ResolveFn(m_func_base_names);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
void SymbolFilePDB::GetMangledNamesForFunction(
|
|
|
|
|
const std::string &scope_qualified_name,
|
2016-04-15 00:21:26 +00:00
|
|
|
std::vector<lldb_private::ConstString> &mangled_names) {}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
[Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
2018-11-30 06:56:37 +00:00
|
|
|
void SymbolFilePDB::AddSymbols(lldb_private::Symtab &symtab) {
|
|
|
|
|
std::set<lldb::addr_t> sym_addresses;
|
|
|
|
|
for (size_t i = 0; i < symtab.GetNumSymbols(); i++)
|
|
|
|
|
sym_addresses.insert(symtab.SymbolAtIndex(i)->GetFileAddress());
|
|
|
|
|
|
|
|
|
|
auto results = m_global_scope_up->findAllChildren<PDBSymbolPublicSymbol>();
|
|
|
|
|
if (!results)
|
|
|
|
|
return;
|
|
|
|
|
|
2019-07-31 08:25:25 +00:00
|
|
|
auto section_list = m_objfile_sp->GetSectionList();
|
[Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
2018-11-30 06:56:37 +00:00
|
|
|
if (!section_list)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
while (auto pub_symbol = results->getNext()) {
|
ObjectFilePECOFF: Create a "container" section spanning the entire module image
Summary:
This is coming from the discussion in D55356 (the most interesting part
happened on the mailing list, so it isn't reflected on the review page).
In short the issue is that lldb assumes that all bytes of a module image
in memory will be backed by a "section". This isn't the case for PECOFF
files because the initial bytes of the module image will contain the
file header, which does not correspond to any normal section in the
file. In particular, this means it is not possible to implement
GetBaseAddress function for PECOFF files, because that's supposed point
to the first byte of that header.
If my (limited) understanding of how PECOFF files work is correct, then
the OS is expecded to load the entire module into one continuous chunk
of memory. The address of that chunk (+/- ASLR) is given by the "image
base" field in the COFF header, and it's size by "image size". All of
the COFF sections are then loaded into this range.
If that's true, then we can model this behavior in lldb by creating a
"container" section to represent the entire module image, and then place
other sections inside that. This would make be consistent with how MachO
and ELF files are modelled (except that those can have multiple
top-level containers as they can be loaded into multiple discontinuous
chunks of memory).
This change required a small number of fixups in the PDB plugins, which
assumed a certain order of sections within the object file (which
obivously changes now). I fix this by changing the lookup code to use
section IDs (which are unchanged) instead of indexes. This has the nice
benefit of removing spurious -1s in the plugins as the section IDs in
the pdbs match the 1-based section IDs in the COFF plugin.
Besides making the implementation of GetBaseAddress possible, this also
improves the lookup of addresses in the gaps between the object file
sections, which will now be correctly resolved as belonging to the
object file.
Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo
Reviewed By: clayborg, lemo
Subscribers: JDevlieghere, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56537
llvm-svn: 353916
2019-02-13 07:17:24 +00:00
|
|
|
auto section_id = pub_symbol->getAddressSection();
|
[Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
2018-11-30 06:56:37 +00:00
|
|
|
|
ObjectFilePECOFF: Create a "container" section spanning the entire module image
Summary:
This is coming from the discussion in D55356 (the most interesting part
happened on the mailing list, so it isn't reflected on the review page).
In short the issue is that lldb assumes that all bytes of a module image
in memory will be backed by a "section". This isn't the case for PECOFF
files because the initial bytes of the module image will contain the
file header, which does not correspond to any normal section in the
file. In particular, this means it is not possible to implement
GetBaseAddress function for PECOFF files, because that's supposed point
to the first byte of that header.
If my (limited) understanding of how PECOFF files work is correct, then
the OS is expecded to load the entire module into one continuous chunk
of memory. The address of that chunk (+/- ASLR) is given by the "image
base" field in the COFF header, and it's size by "image size". All of
the COFF sections are then loaded into this range.
If that's true, then we can model this behavior in lldb by creating a
"container" section to represent the entire module image, and then place
other sections inside that. This would make be consistent with how MachO
and ELF files are modelled (except that those can have multiple
top-level containers as they can be loaded into multiple discontinuous
chunks of memory).
This change required a small number of fixups in the PDB plugins, which
assumed a certain order of sections within the object file (which
obivously changes now). I fix this by changing the lookup code to use
section IDs (which are unchanged) instead of indexes. This has the nice
benefit of removing spurious -1s in the plugins as the section IDs in
the pdbs match the 1-based section IDs in the COFF plugin.
Besides making the implementation of GetBaseAddress possible, this also
improves the lookup of addresses in the gaps between the object file
sections, which will now be correctly resolved as belonging to the
object file.
Reviewers: zturner, amccarth, stella.stamenova, clayborg, lemo
Reviewed By: clayborg, lemo
Subscribers: JDevlieghere, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D56537
llvm-svn: 353916
2019-02-13 07:17:24 +00:00
|
|
|
auto section = section_list->FindSectionByID(section_id);
|
[Symbol] Search symbols with name and type in a symbol file
Summary:
This patch adds possibility of searching a public symbol with name and type in
a symbol file, not only in a symtab. It is helpful when working with PE, because
PE's symtabs contain only imported / exported symbols only. Such a search is
required for e.g. evaluation of an expression that calls some function of
the debuggee.
Reviewers: zturner, asmith, labath, clayborg, espindola
Reviewed By: clayborg
Subscribers: davide, emaste, arichardson, aleksandr.urakov, jingham,
lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53368
llvm-svn: 347960
2018-11-30 06:56:37 +00:00
|
|
|
if (!section)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto offset = pub_symbol->getAddressOffset();
|
|
|
|
|
|
|
|
|
|
auto file_addr = section->GetFileAddress() + offset;
|
|
|
|
|
if (sym_addresses.find(file_addr) != sym_addresses.end())
|
|
|
|
|
continue;
|
|
|
|
|
sym_addresses.insert(file_addr);
|
|
|
|
|
|
|
|
|
|
auto size = pub_symbol->getLength();
|
|
|
|
|
symtab.AddSymbol(
|
|
|
|
|
Symbol(pub_symbol->getSymIndexId(), // symID
|
|
|
|
|
pub_symbol->getName().c_str(), // name
|
|
|
|
|
pub_symbol->isCode() ? eSymbolTypeCode : eSymbolTypeData, // type
|
|
|
|
|
true, // external
|
|
|
|
|
false, // is_debug
|
|
|
|
|
false, // is_trampoline
|
|
|
|
|
false, // is_artificial
|
|
|
|
|
section, // section_sp
|
|
|
|
|
offset, // value
|
|
|
|
|
size, // size
|
|
|
|
|
size != 0, // size_is_valid
|
|
|
|
|
false, // contains_linker_annotations
|
|
|
|
|
0 // flags
|
|
|
|
|
));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
symtab.Finalize();
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-05 17:40:28 +00:00
|
|
|
void SymbolFilePDB::DumpClangAST(Stream &s) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to dump ClangAST: {0}");
|
2018-11-05 17:40:28 +00:00
|
|
|
return;
|
2019-07-30 22:12:34 +00:00
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
|
|
|
|
TypeSystemClang *clang_type_system =
|
|
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
2019-07-30 22:12:34 +00:00
|
|
|
if (!clang_type_system)
|
|
|
|
|
return;
|
2021-10-19 11:51:10 +02:00
|
|
|
clang_type_system->Dump(s.AsRawOstream());
|
2018-11-05 17:40:28 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
void SymbolFilePDB::FindTypesByRegex(
|
|
|
|
|
const lldb_private::RegularExpression ®ex, uint32_t max_matches,
|
|
|
|
|
lldb_private::TypeMap &types) {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// When searching by regex, we need to go out of our way to limit the search
|
2017-01-27 21:42:28 +00:00
|
|
|
// space as much as possible since this searches EVERYTHING in the PDB,
|
|
|
|
|
// manually doing regex comparisons. PDB library isn't optimized for regex
|
|
|
|
|
// searches or searches across multiple symbol types at the same time, so the
|
2016-04-15 00:21:26 +00:00
|
|
|
// best we can do is to search enums, then typedefs, then classes one by one,
|
2017-01-27 21:42:28 +00:00
|
|
|
// and do a regex comparison against each of them.
|
2016-05-04 20:33:53 +00:00
|
|
|
PDB_SymType tags_to_search[] = {PDB_SymType::Enum, PDB_SymType::Typedef,
|
|
|
|
|
PDB_SymType::UDT};
|
|
|
|
|
std::unique_ptr<IPDBEnumSymbols> results;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
uint32_t matches = 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
for (auto tag : tags_to_search) {
|
2018-01-13 06:58:18 +00:00
|
|
|
results = m_global_scope_up->findAllChildren(tag);
|
|
|
|
|
if (!results)
|
|
|
|
|
continue;
|
|
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
while (auto result = results->getNext()) {
|
|
|
|
|
if (max_matches > 0 && matches >= max_matches)
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
std::string type_name;
|
|
|
|
|
if (auto enum_type = llvm::dyn_cast<PDBSymbolTypeEnum>(result.get()))
|
2016-04-15 00:21:26 +00:00
|
|
|
type_name = enum_type->getName();
|
2016-05-04 20:33:53 +00:00
|
|
|
else if (auto typedef_type =
|
2018-03-22 03:44:51 +00:00
|
|
|
llvm::dyn_cast<PDBSymbolTypeTypedef>(result.get()))
|
2016-04-15 00:21:26 +00:00
|
|
|
type_name = typedef_type->getName();
|
2016-05-04 20:33:53 +00:00
|
|
|
else if (auto class_type = llvm::dyn_cast<PDBSymbolTypeUDT>(result.get()))
|
2016-04-15 00:21:26 +00:00
|
|
|
type_name = class_type->getName();
|
2016-09-06 20:57:50 +00:00
|
|
|
else {
|
2017-01-27 21:42:28 +00:00
|
|
|
// We're looking only for types that have names. Skip symbols, as well
|
|
|
|
|
// as unnamed types such as arrays, pointers, etc.
|
2016-04-15 00:21:26 +00:00
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2017-12-22 05:26:50 +00:00
|
|
|
if (!regex.Execute(type_name))
|
2016-04-15 00:21:26 +00:00
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
// This should cause the type to get cached and stored in the `m_types`
|
|
|
|
|
// lookup.
|
|
|
|
|
if (!ResolveTypeUID(result->getSymIndexId()))
|
|
|
|
|
continue;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
auto iter = m_types.find(result->getSymIndexId());
|
|
|
|
|
if (iter == m_types.end())
|
|
|
|
|
continue;
|
|
|
|
|
types.Insert(iter->second);
|
|
|
|
|
++matches;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
[lldb] Make only one function that needs to be implemented when searching for types (#74786)
This patch revives the effort to get this Phabricator patch into
upstream:
https://reviews.llvm.org/D137900
This patch was accepted before in Phabricator but I found some
-gsimple-template-names issues that are fixed in this patch.
A fixed up version of the description from the original patch starts
now.
This patch started off trying to fix Module::FindFirstType() as it
sometimes didn't work. The issue was the SymbolFile plug-ins didn't do
any filtering of the matching types they produced, and they only looked
up types using the type basename. This means if you have two types with
the same basename, your type lookup can fail when only looking up a
single type. We would ask the Module::FindFirstType to lookup "Foo::Bar"
and it would ask the symbol file to find only 1 type matching the
basename "Bar", and then we would filter out any matches that didn't
match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it
would work, but if it found "Baz::Bar" first, it would return only that
type and it would be filtered out.
Discovering this issue lead me to think of the patch Alex Langford did a
few months ago that was done for finding functions, where he allowed
SymbolFile objects to make sure something fully matched before parsing
the debug information into an AST type and other LLDB types. So this
patch aimed to allow type lookups to also be much more efficient.
As LLDB has been developed over the years, we added more ways to to type
lookups. These functions have lots of arguments. This patch aims to make
one API that needs to be implemented that serves all previous lookups:
- Find a single type
- Find all types
- Find types in a namespace
This patch introduces a `TypeQuery` class that contains all of the state
needed to perform the lookup which is powerful enough to perform all of
the type searches that used to be in our API. It contain a vector of
CompilerContext objects that can fully or partially specify the lookup
that needs to take place.
If you just want to lookup all types with a matching basename,
regardless of the containing context, you can specify just a single
CompilerContext entry that has a name and a CompilerContextKind mask of
CompilerContextKind::AnyType.
Or you can fully specify the exact context to use when doing lookups
like: CompilerContextKind::Namespace "std"
CompilerContextKind::Class "foo"
CompilerContextKind::Typedef "size_type"
This change expands on the clang modules code that already used a
vector<CompilerContext> items, but it modifies it to work with
expression type lookups which have contexts, or user lookups where users
query for types. The clang modules type lookup is still an option that
can be enabled on the `TypeQuery` objects.
This mirrors the most recent addition of type lookups that took a
vector<CompilerContext> that allowed lookups to happen for the
expression parser in certain places.
Prior to this we had the following APIs in Module:
```
void
Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeList &types);
void
Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeMap &types);
void Module::FindTypesInNamespace(ConstString type_name,
const CompilerDeclContext &parent_decl_ctx,
size_t max_matches, TypeList &type_list);
```
The new Module API is much simpler. It gets rid of all three above
functions and replaces them with:
```
void FindTypes(const TypeQuery &query, TypeResults &results);
```
The `TypeQuery` class contains all of the needed settings:
- The vector<CompilerContext> that allow efficient lookups in the symbol
file classes since they can look at basename matches only realize fully
matching types. Before this any basename that matched was fully realized
only to be removed later by code outside of the SymbolFile layer which
could cause many types to be realized when they didn't need to.
- If the lookup is exact or not. If not exact, then the compiler context
must match the bottom most items that match the compiler context,
otherwise it must match exactly
- If the compiler context match is for clang modules or not. Clang
modules matches include a Module compiler context kind that allows types
to be matched only from certain modules and these matches are not needed
when d oing user type lookups.
- An optional list of languages to use to limit the search to only
certain languages
The `TypeResults` object contains all state required to do the lookup
and store the results:
- The max number of matches
- The set of SymbolFile objects that have already been searched
- The matching type list for any matches that are found
The benefits of this approach are:
- Simpler API, and only one API to implement in SymbolFile classes
- Replaces the FindTypesInNamespace that used a CompilerDeclContext as a
way to limit the search, but this only worked if the TypeSystem matched
the current symbol file's type system, so you couldn't use it to lookup
a type in another module
- Fixes a serious bug in our FindFirstType functions where if we were
searching for "foo::bar", and we found a "baz::bar" first, the basename
would match and we would only fetch 1 type using the basename, only to
drop it from the matching list and returning no results
2023-12-12 16:51:49 -08:00
|
|
|
void SymbolFilePDB::FindTypes(const lldb_private::TypeQuery &query,
|
|
|
|
|
lldb_private::TypeResults &type_results) {
|
|
|
|
|
|
|
|
|
|
// Make sure we haven't already searched this SymbolFile before.
|
|
|
|
|
if (type_results.AlreadySearched(this))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
std::unique_ptr<IPDBEnumSymbols> results;
|
[lldb] Make only one function that needs to be implemented when searching for types (#74786)
This patch revives the effort to get this Phabricator patch into
upstream:
https://reviews.llvm.org/D137900
This patch was accepted before in Phabricator but I found some
-gsimple-template-names issues that are fixed in this patch.
A fixed up version of the description from the original patch starts
now.
This patch started off trying to fix Module::FindFirstType() as it
sometimes didn't work. The issue was the SymbolFile plug-ins didn't do
any filtering of the matching types they produced, and they only looked
up types using the type basename. This means if you have two types with
the same basename, your type lookup can fail when only looking up a
single type. We would ask the Module::FindFirstType to lookup "Foo::Bar"
and it would ask the symbol file to find only 1 type matching the
basename "Bar", and then we would filter out any matches that didn't
match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it
would work, but if it found "Baz::Bar" first, it would return only that
type and it would be filtered out.
Discovering this issue lead me to think of the patch Alex Langford did a
few months ago that was done for finding functions, where he allowed
SymbolFile objects to make sure something fully matched before parsing
the debug information into an AST type and other LLDB types. So this
patch aimed to allow type lookups to also be much more efficient.
As LLDB has been developed over the years, we added more ways to to type
lookups. These functions have lots of arguments. This patch aims to make
one API that needs to be implemented that serves all previous lookups:
- Find a single type
- Find all types
- Find types in a namespace
This patch introduces a `TypeQuery` class that contains all of the state
needed to perform the lookup which is powerful enough to perform all of
the type searches that used to be in our API. It contain a vector of
CompilerContext objects that can fully or partially specify the lookup
that needs to take place.
If you just want to lookup all types with a matching basename,
regardless of the containing context, you can specify just a single
CompilerContext entry that has a name and a CompilerContextKind mask of
CompilerContextKind::AnyType.
Or you can fully specify the exact context to use when doing lookups
like: CompilerContextKind::Namespace "std"
CompilerContextKind::Class "foo"
CompilerContextKind::Typedef "size_type"
This change expands on the clang modules code that already used a
vector<CompilerContext> items, but it modifies it to work with
expression type lookups which have contexts, or user lookups where users
query for types. The clang modules type lookup is still an option that
can be enabled on the `TypeQuery` objects.
This mirrors the most recent addition of type lookups that took a
vector<CompilerContext> that allowed lookups to happen for the
expression parser in certain places.
Prior to this we had the following APIs in Module:
```
void
Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeList &types);
void
Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeMap &types);
void Module::FindTypesInNamespace(ConstString type_name,
const CompilerDeclContext &parent_decl_ctx,
size_t max_matches, TypeList &type_list);
```
The new Module API is much simpler. It gets rid of all three above
functions and replaces them with:
```
void FindTypes(const TypeQuery &query, TypeResults &results);
```
The `TypeQuery` class contains all of the needed settings:
- The vector<CompilerContext> that allow efficient lookups in the symbol
file classes since they can look at basename matches only realize fully
matching types. Before this any basename that matched was fully realized
only to be removed later by code outside of the SymbolFile layer which
could cause many types to be realized when they didn't need to.
- If the lookup is exact or not. If not exact, then the compiler context
must match the bottom most items that match the compiler context,
otherwise it must match exactly
- If the compiler context match is for clang modules or not. Clang
modules matches include a Module compiler context kind that allows types
to be matched only from certain modules and these matches are not needed
when d oing user type lookups.
- An optional list of languages to use to limit the search to only
certain languages
The `TypeResults` object contains all state required to do the lookup
and store the results:
- The max number of matches
- The set of SymbolFile objects that have already been searched
- The matching type list for any matches that are found
The benefits of this approach are:
- Simpler API, and only one API to implement in SymbolFile classes
- Replaces the FindTypesInNamespace that used a CompilerDeclContext as a
way to limit the search, but this only worked if the TypeSystem matched
the current symbol file's type system, so you couldn't use it to lookup
a type in another module
- Fixes a serious bug in our FindFirstType functions where if we were
searching for "foo::bar", and we found a "baz::bar" first, the basename
would match and we would only fetch 1 type using the basename, only to
drop it from the matching list and returning no results
2023-12-12 16:51:49 -08:00
|
|
|
llvm::StringRef basename = query.GetTypeBasename().GetStringRef();
|
|
|
|
|
if (basename.empty())
|
2018-03-07 03:16:50 +00:00
|
|
|
return;
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
results = m_global_scope_up->findAllChildren(PDB_SymType::None);
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!results)
|
|
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
while (auto result = results->getNext()) {
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
switch (result->getSymTag()) {
|
2016-05-04 20:33:53 +00:00
|
|
|
case PDB_SymType::Enum:
|
|
|
|
|
case PDB_SymType::UDT:
|
|
|
|
|
case PDB_SymType::Typedef:
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
|
|
|
|
default:
|
2018-04-30 16:49:04 +00:00
|
|
|
// We're looking only for types that have names. Skip symbols, as well
|
|
|
|
|
// as unnamed types such as arrays, pointers, etc.
|
2016-04-15 00:21:26 +00:00
|
|
|
continue;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2023-12-15 03:55:40 -08:00
|
|
|
if (MSVCUndecoratedNameParser::DropScope(
|
|
|
|
|
result->getRawSymbol().getName()) != basename)
|
|
|
|
|
continue;
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// This should cause the type to get cached and stored in the `m_types`
|
2016-04-15 00:21:26 +00:00
|
|
|
// lookup.
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!ResolveTypeUID(result->getSymIndexId()))
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto iter = m_types.find(result->getSymIndexId());
|
|
|
|
|
if (iter == m_types.end())
|
2016-04-15 00:21:26 +00:00
|
|
|
continue;
|
[lldb] Make only one function that needs to be implemented when searching for types (#74786)
This patch revives the effort to get this Phabricator patch into
upstream:
https://reviews.llvm.org/D137900
This patch was accepted before in Phabricator but I found some
-gsimple-template-names issues that are fixed in this patch.
A fixed up version of the description from the original patch starts
now.
This patch started off trying to fix Module::FindFirstType() as it
sometimes didn't work. The issue was the SymbolFile plug-ins didn't do
any filtering of the matching types they produced, and they only looked
up types using the type basename. This means if you have two types with
the same basename, your type lookup can fail when only looking up a
single type. We would ask the Module::FindFirstType to lookup "Foo::Bar"
and it would ask the symbol file to find only 1 type matching the
basename "Bar", and then we would filter out any matches that didn't
match "Foo::Bar". So if the SymbolFile found "Foo::Bar" first, then it
would work, but if it found "Baz::Bar" first, it would return only that
type and it would be filtered out.
Discovering this issue lead me to think of the patch Alex Langford did a
few months ago that was done for finding functions, where he allowed
SymbolFile objects to make sure something fully matched before parsing
the debug information into an AST type and other LLDB types. So this
patch aimed to allow type lookups to also be much more efficient.
As LLDB has been developed over the years, we added more ways to to type
lookups. These functions have lots of arguments. This patch aims to make
one API that needs to be implemented that serves all previous lookups:
- Find a single type
- Find all types
- Find types in a namespace
This patch introduces a `TypeQuery` class that contains all of the state
needed to perform the lookup which is powerful enough to perform all of
the type searches that used to be in our API. It contain a vector of
CompilerContext objects that can fully or partially specify the lookup
that needs to take place.
If you just want to lookup all types with a matching basename,
regardless of the containing context, you can specify just a single
CompilerContext entry that has a name and a CompilerContextKind mask of
CompilerContextKind::AnyType.
Or you can fully specify the exact context to use when doing lookups
like: CompilerContextKind::Namespace "std"
CompilerContextKind::Class "foo"
CompilerContextKind::Typedef "size_type"
This change expands on the clang modules code that already used a
vector<CompilerContext> items, but it modifies it to work with
expression type lookups which have contexts, or user lookups where users
query for types. The clang modules type lookup is still an option that
can be enabled on the `TypeQuery` objects.
This mirrors the most recent addition of type lookups that took a
vector<CompilerContext> that allowed lookups to happen for the
expression parser in certain places.
Prior to this we had the following APIs in Module:
```
void
Module::FindTypes(ConstString type_name, bool exact_match, size_t max_matches,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeList &types);
void
Module::FindTypes(llvm::ArrayRef<CompilerContext> pattern, LanguageSet languages,
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files,
TypeMap &types);
void Module::FindTypesInNamespace(ConstString type_name,
const CompilerDeclContext &parent_decl_ctx,
size_t max_matches, TypeList &type_list);
```
The new Module API is much simpler. It gets rid of all three above
functions and replaces them with:
```
void FindTypes(const TypeQuery &query, TypeResults &results);
```
The `TypeQuery` class contains all of the needed settings:
- The vector<CompilerContext> that allow efficient lookups in the symbol
file classes since they can look at basename matches only realize fully
matching types. Before this any basename that matched was fully realized
only to be removed later by code outside of the SymbolFile layer which
could cause many types to be realized when they didn't need to.
- If the lookup is exact or not. If not exact, then the compiler context
must match the bottom most items that match the compiler context,
otherwise it must match exactly
- If the compiler context match is for clang modules or not. Clang
modules matches include a Module compiler context kind that allows types
to be matched only from certain modules and these matches are not needed
when d oing user type lookups.
- An optional list of languages to use to limit the search to only
certain languages
The `TypeResults` object contains all state required to do the lookup
and store the results:
- The max number of matches
- The set of SymbolFile objects that have already been searched
- The matching type list for any matches that are found
The benefits of this approach are:
- Simpler API, and only one API to implement in SymbolFile classes
- Replaces the FindTypesInNamespace that used a CompilerDeclContext as a
way to limit the search, but this only worked if the TypeSystem matched
the current symbol file's type system, so you couldn't use it to lookup
a type in another module
- Fixes a serious bug in our FindFirstType functions where if we were
searching for "foo::bar", and we found a "baz::bar" first, the basename
would match and we would only fetch 1 type using the basename, only to
drop it from the matching list and returning no results
2023-12-12 16:51:49 -08:00
|
|
|
// We resolved a type. Get the fully qualified name to ensure it matches.
|
|
|
|
|
ConstString name = iter->second->GetQualifiedName();
|
|
|
|
|
TypeQuery type_match(name.GetStringRef(), TypeQueryOptions::e_exact_match);
|
|
|
|
|
if (query.ContextMatches(type_match.GetContextRef())) {
|
|
|
|
|
type_results.InsertUnique(iter->second);
|
|
|
|
|
if (type_results.Done(query))
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
void SymbolFilePDB::GetTypesForPDBSymbol(const llvm::pdb::PDBSymbol &pdb_symbol,
|
|
|
|
|
uint32_t type_mask,
|
|
|
|
|
TypeCollection &type_collection) {
|
2018-02-09 05:31:28 +00:00
|
|
|
bool can_parse = false;
|
2018-03-19 21:14:19 +00:00
|
|
|
switch (pdb_symbol.getSymTag()) {
|
2018-02-09 05:31:28 +00:00
|
|
|
case PDB_SymType::ArrayType:
|
|
|
|
|
can_parse = ((type_mask & eTypeClassArray) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::BuiltinType:
|
|
|
|
|
can_parse = ((type_mask & eTypeClassBuiltin) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::Enum:
|
|
|
|
|
can_parse = ((type_mask & eTypeClassEnumeration) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::Function:
|
|
|
|
|
case PDB_SymType::FunctionSig:
|
|
|
|
|
can_parse = ((type_mask & eTypeClassFunction) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::PointerType:
|
|
|
|
|
can_parse = ((type_mask & (eTypeClassPointer | eTypeClassBlockPointer |
|
|
|
|
|
eTypeClassMemberPointer)) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::Typedef:
|
|
|
|
|
can_parse = ((type_mask & eTypeClassTypedef) != 0);
|
|
|
|
|
break;
|
|
|
|
|
case PDB_SymType::UDT: {
|
2018-03-19 21:14:19 +00:00
|
|
|
auto *udt = llvm::dyn_cast<PDBSymbolTypeUDT>(&pdb_symbol);
|
2018-02-09 05:31:28 +00:00
|
|
|
assert(udt);
|
|
|
|
|
can_parse = (udt->getUdtKind() != PDB_UdtType::Interface &&
|
2018-03-22 03:44:51 +00:00
|
|
|
((type_mask & (eTypeClassClass | eTypeClassStruct |
|
|
|
|
|
eTypeClassUnion)) != 0));
|
2018-02-09 05:31:28 +00:00
|
|
|
} break;
|
2018-03-22 03:44:51 +00:00
|
|
|
default:
|
|
|
|
|
break;
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (can_parse) {
|
2018-03-19 21:14:19 +00:00
|
|
|
if (auto *type = ResolveTypeUID(pdb_symbol.getSymIndexId())) {
|
2022-08-07 00:16:17 -07:00
|
|
|
if (!llvm::is_contained(type_collection, type))
|
2018-02-09 05:31:28 +00:00
|
|
|
type_collection.push_back(type);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-03-19 21:14:19 +00:00
|
|
|
auto results_up = pdb_symbol.findAllChildren();
|
2018-02-09 05:31:28 +00:00
|
|
|
while (auto symbol_up = results_up->getNext())
|
2018-03-19 21:14:19 +00:00
|
|
|
GetTypesForPDBSymbol(*symbol_up, type_mask, type_collection);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
|
2019-10-01 15:29:33 +00:00
|
|
|
void SymbolFilePDB::GetTypes(lldb_private::SymbolContextScope *sc_scope,
|
|
|
|
|
TypeClass type_mask,
|
|
|
|
|
lldb_private::TypeList &type_list) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2018-02-09 05:31:28 +00:00
|
|
|
TypeCollection type_collection;
|
2018-03-22 03:44:51 +00:00
|
|
|
CompileUnit *cu =
|
|
|
|
|
sc_scope ? sc_scope->CalculateSymbolContextCompileUnit() : nullptr;
|
2018-02-09 05:31:28 +00:00
|
|
|
if (cu) {
|
|
|
|
|
auto compiland_up = GetPDBCompilandByUID(cu->GetID());
|
2018-03-19 21:14:19 +00:00
|
|
|
if (!compiland_up)
|
2019-10-01 15:29:33 +00:00
|
|
|
return;
|
2018-03-19 21:14:19 +00:00
|
|
|
GetTypesForPDBSymbol(*compiland_up, type_mask, type_collection);
|
2018-02-09 05:31:28 +00:00
|
|
|
} else {
|
|
|
|
|
for (uint32_t cu_idx = 0; cu_idx < GetNumCompileUnits(); ++cu_idx) {
|
|
|
|
|
auto cu_sp = ParseCompileUnitAtIndex(cu_idx);
|
2018-03-22 19:21:34 +00:00
|
|
|
if (cu_sp) {
|
2018-03-19 21:14:19 +00:00
|
|
|
if (auto compiland_up = GetPDBCompilandByUID(cu_sp->GetID()))
|
|
|
|
|
GetTypesForPDBSymbol(*compiland_up, type_mask, type_collection);
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (auto type : type_collection) {
|
|
|
|
|
type->GetForwardCompilerType();
|
|
|
|
|
type_list.Insert(type->shared_from_this());
|
|
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::Expected<lldb::TypeSystemSP>
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
SymbolFilePDB::GetTypeSystemForLanguage(lldb::LanguageType language) {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
2019-07-31 08:25:25 +00:00
|
|
|
m_objfile_sp->GetModule()->GetTypeSystemForLanguage(language);
|
2019-07-30 22:12:34 +00:00
|
|
|
if (type_system_or_err) {
|
2022-11-14 16:24:36 -08:00
|
|
|
if (auto ts = *type_system_or_err)
|
|
|
|
|
ts->SetSymbolFile(this);
|
2019-07-30 22:12:34 +00:00
|
|
|
}
|
|
|
|
|
return type_system_or_err;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
PDBASTParser *SymbolFilePDB::GetPDBAstParser() {
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to get PDB AST parser: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
2019-07-30 22:12:34 +00:00
|
|
|
auto *clang_type_system =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
Change lldb-test to use ParseAllDebugSymbols.
ParseDeclsForContext was originally created to serve the very specific
case where the context is a function block. It was never intended to be
used for arbitrary DeclContexts, however due to the generic name, the
DWARF and PDB plugins implemented it in this way "just in case". Then,
lldb-test came along and decided to use it in that way.
Related to this, there are a set of functions in the SymbolFile class
interface whose requirements and expectations are not documented. For
example, if you call ParseCompileUnitFunctions, there's an inherent
requirement that you create entries in the underlying clang AST for
these functions as well as their signature types, because in order to
create an lldb_private::Function object, you have to pass it a
CompilerType for the parameter representing the signature.
On the other hand, there is no similar requirement (either inherent or
documented) if one were to call ParseDeclsForContext. Specifically, if
one calls ParseDeclsForContext, and some variable declarations, types,
and other things are added to the clang AST, is it necessary to create
lldb::Variable, lldb::Type, etc objects representing them? Nobody knows.
There is, however, an accidental requirement, because since all of the
plugins implemented this just in case, lldb-test came along and used
ParsedDeclsForContext, and then wrote check lines that depended on this.
When I went to try and implemented the NativePDB reader, I did not
adhere to this (in fact, from a layering perspective I went out of my
way to avoid it), and as a result the existing DIA PDB tests don't work
when the native PDB reader is enabled, because they expect that calling
ParseDeclsForContext will modify the *module's* view of symbols, and not
just the internal AST.
All of this confusion, however, can be avoided if we simply stick to
using ParseDeclsForContext for its original intended use case (blocks),
and use a different function (ParseAllDebugSymbols) for its intended use
case which is, unsuprisingly, to parse all the debug symbols (which is
all lldb-test really wanted to do anyway).
In the future, I would like to change ParseDeclsForContext to
ParseDeclsForFunctionBlock, then delete all of the dead code inside that
handles other types of DeclContexts (and probably even assert if the
DeclContext is anything other than a block).
A few PDB tests needed to be fixed up as a result of this, and this also
exposed a couple of bugs in the DIA PDB reader (doesn't matter much
since it should be going away soon, but worth mentioning) where the
appropriate AST entries weren't being created always.
Differential Revision: https://reviews.llvm.org/D56418
llvm-svn: 350764
2019-01-09 21:20:44 +00:00
|
|
|
if (!clang_type_system)
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
|
|
return clang_type_system->GetPDBParser();
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-17 19:25:52 +01:00
|
|
|
lldb_private::CompilerDeclContext
|
|
|
|
|
SymbolFilePDB::FindNamespace(lldb_private::ConstString name,
|
2023-04-03 11:09:23 +01:00
|
|
|
const CompilerDeclContext &parent_decl_ctx, bool) {
|
2019-07-30 08:20:05 +00:00
|
|
|
std::lock_guard<std::recursive_mutex> guard(GetModuleMutex());
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err =
|
|
|
|
|
GetTypeSystemForLanguage(lldb::eLanguageTypeC_plus_plus);
|
|
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
2022-01-31 15:57:48 +01:00
|
|
|
LLDB_LOG_ERROR(GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to find namespace {1}: {0}", name.AsCString());
|
2019-07-30 22:12:34 +00:00
|
|
|
return CompilerDeclContext();
|
|
|
|
|
}
|
2022-11-14 16:24:36 -08:00
|
|
|
auto ts = *type_system_or_err;
|
2019-07-30 22:12:34 +00:00
|
|
|
auto *clang_type_system =
|
2022-11-14 16:24:36 -08:00
|
|
|
llvm::dyn_cast_or_null<TypeSystemClang>(ts.get());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
if (!clang_type_system)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
PDBASTParser *pdb = clang_type_system->GetPDBParser();
|
|
|
|
|
if (!pdb)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
|
|
|
|
clang::DeclContext *decl_context = nullptr;
|
|
|
|
|
if (parent_decl_ctx)
|
|
|
|
|
decl_context = static_cast<clang::DeclContext *>(
|
2020-02-17 19:25:52 +01:00
|
|
|
parent_decl_ctx.GetOpaqueDeclContext());
|
[PDB] Restore AST from PDB symbols
Summary:
This patch adds an implementation of retrieving of declarations and declaration
contexts based on PDB symbols.
PDB has different type symbols for const-qualified types, and this
implementation ensures that only one declaration was created for both const
and non-const types, but creates different compiler types for them.
The implementation also processes the case when there are two symbols
corresponding to a variable. It's possible e.g. for class static variables,
they has one global symbol and one symbol belonging to a class.
PDB has no info about namespaces, so this implementation parses the full symbol
name and tries to figure out if the symbol belongs to namespace or not,
and then creates nested namespaces if necessary.
Reviewers: asmith, zturner, labath
Reviewed By: asmith
Subscribers: aleksandr.urakov, teemperor, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D51162
llvm-svn: 341782
2018-09-10 08:08:43 +00:00
|
|
|
|
|
|
|
|
auto namespace_decl =
|
|
|
|
|
pdb->FindNamespaceDecl(decl_context, name.GetStringRef());
|
|
|
|
|
if (!namespace_decl)
|
|
|
|
|
return CompilerDeclContext();
|
|
|
|
|
|
2019-12-23 09:05:07 +01:00
|
|
|
return clang_type_system->CreateDeclContext(namespace_decl);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2016-05-04 20:33:53 +00:00
|
|
|
IPDBSession &SymbolFilePDB::GetPDBSession() { return *m_session_up; }
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-04-15 00:21:26 +00:00
|
|
|
const IPDBSession &SymbolFilePDB::GetPDBSession() const {
|
|
|
|
|
return *m_session_up;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-03-22 03:44:51 +00:00
|
|
|
lldb::CompUnitSP SymbolFilePDB::ParseCompileUnitForUID(uint32_t id,
|
|
|
|
|
uint32_t index) {
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
auto found_cu = m_comp_units.find(id);
|
|
|
|
|
if (found_cu != m_comp_units.end())
|
|
|
|
|
return found_cu->second;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
auto compiland_up = GetPDBCompilandByUID(id);
|
|
|
|
|
if (!compiland_up)
|
|
|
|
|
return CompUnitSP();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
lldb::LanguageType lang;
|
2018-01-13 06:58:18 +00:00
|
|
|
auto details = compiland_up->findOneChild<PDBSymbolCompilandDetails>();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (!details)
|
|
|
|
|
lang = lldb::eLanguageTypeC_plus_plus;
|
|
|
|
|
else
|
|
|
|
|
lang = TranslateLanguage(details->getLanguage());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-03-07 03:16:50 +00:00
|
|
|
if (lang == lldb::LanguageType::eLanguageTypeUnknown)
|
|
|
|
|
return CompUnitSP();
|
|
|
|
|
|
2018-03-20 00:18:22 +00:00
|
|
|
std::string path = compiland_up->getSourceFileFullPath();
|
2018-03-07 03:16:50 +00:00
|
|
|
if (path.empty())
|
|
|
|
|
return CompUnitSP();
|
|
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// Don't support optimized code for now, DebugInfoPDB does not return this
|
|
|
|
|
// information.
|
|
|
|
|
LazyBool optimized = eLazyBoolNo;
|
2019-07-31 08:25:25 +00:00
|
|
|
auto cu_sp = std::make_shared<CompileUnit>(m_objfile_sp->GetModule(), nullptr,
|
2018-03-22 03:44:51 +00:00
|
|
|
path.c_str(), id, lang, optimized);
|
2018-01-13 06:58:18 +00:00
|
|
|
|
|
|
|
|
if (!cu_sp)
|
|
|
|
|
return CompUnitSP();
|
|
|
|
|
|
|
|
|
|
m_comp_units.insert(std::make_pair(id, cu_sp));
|
|
|
|
|
if (index == UINT32_MAX)
|
2018-03-19 21:14:19 +00:00
|
|
|
GetCompileUnitIndex(*compiland_up, index);
|
2018-01-13 06:58:18 +00:00
|
|
|
lldbassert(index != UINT32_MAX);
|
2019-07-23 09:24:02 +00:00
|
|
|
SetCompileUnitAtIndex(index, cu_sp);
|
2018-01-13 06:58:18 +00:00
|
|
|
return cu_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2019-01-11 18:03:20 +00:00
|
|
|
bool SymbolFilePDB::ParseCompileUnitLineTable(CompileUnit &comp_unit,
|
|
|
|
|
uint32_t match_line) {
|
|
|
|
|
auto compiland_up = GetPDBCompilandByUID(comp_unit.GetID());
|
2018-01-13 06:58:18 +00:00
|
|
|
if (!compiland_up)
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
// LineEntry needs the *index* of the file into the list of support files
|
2017-01-27 21:42:28 +00:00
|
|
|
// returned by ParseCompileUnitSupportFiles. But the underlying SDK gives us
|
2018-04-30 16:49:04 +00:00
|
|
|
// a globally unique idenfitifier in the namespace of the PDB. So, we have
|
|
|
|
|
// to do a mapping so that we can hand out indices.
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
llvm::DenseMap<uint32_t, uint32_t> index_map;
|
2018-01-13 06:58:18 +00:00
|
|
|
BuildSupportFileIdToSupportFileIndexMap(*compiland_up, index_map);
|
2020-01-28 17:15:26 +01:00
|
|
|
auto line_table = std::make_unique<LineTable>(&comp_unit);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
// Find contributions to `compiland` from all source and header files.
|
|
|
|
|
auto files = m_session_up->getSourceFilesForCompiland(*compiland_up);
|
|
|
|
|
if (!files)
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// For each source and header file, create a LineSequence for contributions
|
|
|
|
|
// to the compiland from that file, and add the sequence.
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
while (auto file = files->getNext()) {
|
2020-01-28 17:15:26 +01:00
|
|
|
std::unique_ptr<LineSequence> sequence(
|
|
|
|
|
line_table->CreateLineSequenceContainer());
|
2018-01-13 06:58:18 +00:00
|
|
|
auto lines = m_session_up->findLineNumbers(*compiland_up, *file);
|
|
|
|
|
if (!lines)
|
|
|
|
|
continue;
|
2016-03-10 00:06:26 +00:00
|
|
|
int entry_count = lines->getChildCount();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-10 00:06:26 +00:00
|
|
|
uint64_t prev_addr;
|
|
|
|
|
uint32_t prev_length;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
uint32_t prev_line;
|
|
|
|
|
uint32_t prev_source_idx;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
for (int i = 0; i < entry_count; ++i) {
|
|
|
|
|
auto line = lines->getChildAtIndex(i);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-10 00:06:26 +00:00
|
|
|
uint64_t lno = line->getLineNumber();
|
|
|
|
|
uint64_t addr = line->getVirtualAddress();
|
|
|
|
|
uint32_t length = line->getLength();
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
uint32_t source_id = line->getSourceFileId();
|
2016-03-10 00:06:26 +00:00
|
|
|
uint32_t col = line->getColumnNumber();
|
|
|
|
|
uint32_t source_idx = index_map[source_id];
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// There was a gap between the current entry and the previous entry if
|
|
|
|
|
// the addresses don't perfectly line up.
|
2016-03-10 00:06:26 +00:00
|
|
|
bool is_gap = (i > 0) && (prev_addr + prev_length < addr);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-03-10 00:06:26 +00:00
|
|
|
// Before inserting the current entry, insert a terminal entry at the end
|
2017-01-27 21:42:28 +00:00
|
|
|
// of the previous entry's address range if the current entry resulted in
|
|
|
|
|
// a gap from the previous entry.
|
2016-03-10 00:06:26 +00:00
|
|
|
if (is_gap && ShouldAddLine(match_line, prev_line, prev_length)) {
|
2020-01-28 17:15:26 +01:00
|
|
|
line_table->AppendLineEntryToSequence(
|
2016-03-10 00:06:26 +00:00
|
|
|
sequence.get(), prev_addr + prev_length, prev_line, 0,
|
|
|
|
|
prev_source_idx, false, false, false, false, true);
|
2018-06-08 02:45:25 +00:00
|
|
|
|
2021-04-22 12:29:08 +02:00
|
|
|
line_table->InsertSequence(sequence.get());
|
2020-01-28 17:15:26 +01:00
|
|
|
sequence = line_table->CreateLineSequenceContainer();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2016-03-10 00:06:26 +00:00
|
|
|
if (ShouldAddLine(match_line, lno, length)) {
|
|
|
|
|
bool is_statement = line->isStatement();
|
|
|
|
|
bool is_prologue = false;
|
2016-05-04 20:33:53 +00:00
|
|
|
bool is_epilogue = false;
|
2016-03-10 00:06:26 +00:00
|
|
|
auto func =
|
2016-05-04 20:33:53 +00:00
|
|
|
m_session_up->findSymbolByAddress(addr, PDB_SymType::Function);
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
if (func) {
|
2016-05-04 20:33:53 +00:00
|
|
|
auto prologue = func->findOneChild<PDBSymbolFuncDebugStart>();
|
2018-01-13 06:58:18 +00:00
|
|
|
if (prologue)
|
|
|
|
|
is_prologue = (addr == prologue->getVirtualAddress());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2016-05-04 20:33:53 +00:00
|
|
|
auto epilogue = func->findOneChild<PDBSymbolFuncDebugEnd>();
|
2018-01-13 06:58:18 +00:00
|
|
|
if (epilogue)
|
|
|
|
|
is_epilogue = (addr == epilogue->getVirtualAddress());
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
2016-03-10 00:06:26 +00:00
|
|
|
|
2020-01-28 17:15:26 +01:00
|
|
|
line_table->AppendLineEntryToSequence(sequence.get(), addr, lno, col,
|
|
|
|
|
source_idx, is_statement, false,
|
|
|
|
|
is_prologue, is_epilogue, false);
|
2016-03-10 00:06:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
prev_addr = addr;
|
|
|
|
|
prev_length = length;
|
|
|
|
|
prev_line = lno;
|
|
|
|
|
prev_source_idx = source_idx;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (entry_count > 0 && ShouldAddLine(match_line, prev_line, prev_length)) {
|
|
|
|
|
// The end is always a terminal entry, so insert it regardless.
|
2020-01-28 17:15:26 +01:00
|
|
|
line_table->AppendLineEntryToSequence(
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
sequence.get(), prev_addr + prev_length, prev_line, 0,
|
|
|
|
|
prev_source_idx, false, false, false, false, true);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-01-28 17:15:26 +01:00
|
|
|
line_table->InsertSequence(sequence.get());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-13 06:58:18 +00:00
|
|
|
if (line_table->GetSize()) {
|
2019-01-11 18:03:20 +00:00
|
|
|
comp_unit.SetLineTable(line_table.release());
|
2018-01-13 06:58:18 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2016-05-04 20:33:53 +00:00
|
|
|
void SymbolFilePDB::BuildSupportFileIdToSupportFileIndexMap(
|
2018-01-13 06:58:18 +00:00
|
|
|
const PDBSymbolCompiland &compiland,
|
2016-04-15 00:21:26 +00:00
|
|
|
llvm::DenseMap<uint32_t, uint32_t> &index_map) const {
|
2018-04-30 16:49:04 +00:00
|
|
|
// This is a hack, but we need to convert the source id into an index into
|
|
|
|
|
// the support files array. We don't want to do path comparisons to avoid
|
2017-01-27 21:42:28 +00:00
|
|
|
// basename / full path issues that may or may not even be a problem, so we
|
|
|
|
|
// use the globally unique source file identifiers. Ideally we could use the
|
|
|
|
|
// global identifiers everywhere, but LineEntry currently assumes indices.
|
2018-01-13 06:58:18 +00:00
|
|
|
auto source_files = m_session_up->getSourceFilesForCompiland(compiland);
|
|
|
|
|
if (!source_files)
|
|
|
|
|
return;
|
2018-06-28 10:03:42 +00:00
|
|
|
|
[lldb] Don't put compile unit name into the support file list and support DWARF5 line tables
Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.
While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.
What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.
DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.
I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.
Reviewers: clayborg, JDevlieghere, jdoerfert
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70954
2019-11-28 10:19:23 +01:00
|
|
|
int index = 0;
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
while (auto file = source_files->getNext()) {
|
|
|
|
|
uint32_t source_id = file->getUniqueId();
|
|
|
|
|
index_map[source_id] = index++;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
Add support for reading line tables from PDB files.
PDB is Microsoft's debug information format, and although we
cannot yet generate it, we still must be able to consume it.
Reason for this is that debug information for system libraries
(e.g. kernel32, C Runtime Library, etc) only have debug info
in PDB format, so in order to be able to support debugging
of system code, we must support it.
Currently this code should compile on every platform, but on
non-Windows platforms the PDB plugin will return 0 capabilities,
meaning that for now PDB is only supported on Windows. This
may change in the future, but the API is designed in such a way
that this will require few (if any) changes on the LLDB side.
In the future we can just flip a switch and everything will
work.
This patch only adds support for line tables. It does not return
information about functions, types, global variables, or anything
else. This functionality will be added in a followup patch.
Differential Revision: http://reviews.llvm.org/D17363
Reviewed by: Greg Clayton
llvm-svn: 262528
2016-03-02 22:05:52 +00:00
|
|
|
}
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
lldb::CompUnitSP SymbolFilePDB::GetCompileUnitContainsAddress(
|
2018-03-22 19:26:33 +00:00
|
|
|
const lldb_private::Address &so_addr) {
|
2018-02-09 05:31:28 +00:00
|
|
|
lldb::addr_t file_vm_addr = so_addr.GetFileAddress();
|
2018-03-22 19:26:33 +00:00
|
|
|
if (file_vm_addr == LLDB_INVALID_ADDRESS || file_vm_addr == 0)
|
2018-02-09 05:31:28 +00:00
|
|
|
return nullptr;
|
|
|
|
|
|
2018-03-22 19:26:33 +00:00
|
|
|
// If it is a PDB function's vm addr, this is the first sure bet.
|
|
|
|
|
if (auto lines =
|
|
|
|
|
m_session_up->findLineNumbersByAddress(file_vm_addr, /*Length=*/1)) {
|
|
|
|
|
if (auto first_line = lines->getNext())
|
|
|
|
|
return ParseCompileUnitForUID(first_line->getCompilandId());
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-22 19:26:33 +00:00
|
|
|
// Otherwise we resort to section contributions.
|
|
|
|
|
if (auto sec_contribs = m_session_up->getSectionContribs()) {
|
|
|
|
|
while (auto section = sec_contribs->getNext()) {
|
|
|
|
|
auto va = section->getVirtualAddress();
|
|
|
|
|
if (file_vm_addr >= va && file_vm_addr < va + section->getLength())
|
|
|
|
|
return ParseCompileUnitForUID(section->getCompilandId());
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-02-09 05:31:28 +00:00
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Mangled
|
2018-03-19 21:14:19 +00:00
|
|
|
SymbolFilePDB::GetMangledForPDBFunc(const llvm::pdb::PDBSymbolFunc &pdb_func) {
|
2018-02-09 05:31:28 +00:00
|
|
|
Mangled mangled;
|
2018-03-19 21:14:19 +00:00
|
|
|
auto func_name = pdb_func.getName();
|
|
|
|
|
auto func_undecorated_name = pdb_func.getUndecoratedName();
|
2018-02-09 05:31:28 +00:00
|
|
|
std::string func_decorated_name;
|
|
|
|
|
|
|
|
|
|
// Seek from public symbols for non-static function's decorated name if any.
|
|
|
|
|
// For static functions, they don't have undecorated names and aren't exposed
|
|
|
|
|
// in Public Symbols either.
|
|
|
|
|
if (!func_undecorated_name.empty()) {
|
2018-03-22 03:44:51 +00:00
|
|
|
auto result_up = m_global_scope_up->findChildren(
|
|
|
|
|
PDB_SymType::PublicSymbol, func_undecorated_name,
|
|
|
|
|
PDB_NameSearchFlags::NS_UndecoratedName);
|
2018-02-09 05:31:28 +00:00
|
|
|
if (result_up) {
|
|
|
|
|
while (auto symbol_up = result_up->getNext()) {
|
|
|
|
|
// For a public symbol, it is unique.
|
|
|
|
|
lldbassert(result_up->getChildCount() == 1);
|
|
|
|
|
if (auto *pdb_public_sym =
|
2018-03-22 03:44:51 +00:00
|
|
|
llvm::dyn_cast_or_null<PDBSymbolPublicSymbol>(
|
|
|
|
|
symbol_up.get())) {
|
2018-02-09 05:31:28 +00:00
|
|
|
if (pdb_public_sym->isFunction()) {
|
|
|
|
|
func_decorated_name = pdb_public_sym->getName();
|
2018-03-07 03:16:50 +00:00
|
|
|
break;
|
2018-02-09 05:31:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (!func_decorated_name.empty()) {
|
|
|
|
|
mangled.SetMangledName(ConstString(func_decorated_name));
|
|
|
|
|
|
2022-09-13 09:32:02 -07:00
|
|
|
// For MSVC, format of C function's decorated name depends on calling
|
2020-04-07 01:06:02 +09:00
|
|
|
// convention. Unfortunately none of the format is recognized by current
|
2018-02-09 05:31:28 +00:00
|
|
|
// LLDB. For example, `_purecall` is a __cdecl C function. From PDB,
|
2018-04-30 16:49:04 +00:00
|
|
|
// `__purecall` is retrieved as both its decorated and undecorated name
|
|
|
|
|
// (using PDBSymbolFunc::getUndecoratedName method). However `__purecall`
|
|
|
|
|
// string is not treated as mangled in LLDB (neither `?` nor `_Z` prefix).
|
|
|
|
|
// Mangled::GetDemangledName method will fail internally and caches an
|
2020-04-07 01:06:02 +09:00
|
|
|
// empty string as its undecorated name. So we will face a contradiction
|
2018-04-30 16:49:04 +00:00
|
|
|
// here for the same symbol:
|
2018-02-09 05:31:28 +00:00
|
|
|
// non-empty undecorated name from PDB
|
|
|
|
|
// empty undecorated name from LLDB
|
2020-01-30 21:55:18 -08:00
|
|
|
if (!func_undecorated_name.empty() && mangled.GetDemangledName().IsEmpty())
|
2018-02-09 05:31:28 +00:00
|
|
|
mangled.SetDemangledName(ConstString(func_undecorated_name));
|
|
|
|
|
|
|
|
|
|
// LLDB uses several flags to control how a C++ decorated name is
|
2018-04-30 16:49:04 +00:00
|
|
|
// undecorated for MSVC. See `safeUndecorateName` in Class Mangled. So the
|
|
|
|
|
// yielded name could be different from what we retrieve from
|
2018-02-09 05:31:28 +00:00
|
|
|
// PDB source unless we also apply same flags in getting undecorated
|
|
|
|
|
// name through PDBSymbolFunc::getUndecoratedNameEx method.
|
|
|
|
|
if (!func_undecorated_name.empty() &&
|
2020-01-30 21:55:18 -08:00
|
|
|
mangled.GetDemangledName() != ConstString(func_undecorated_name))
|
2018-02-09 05:31:28 +00:00
|
|
|
mangled.SetDemangledName(ConstString(func_undecorated_name));
|
|
|
|
|
} else if (!func_undecorated_name.empty()) {
|
|
|
|
|
mangled.SetDemangledName(ConstString(func_undecorated_name));
|
|
|
|
|
} else if (!func_name.empty())
|
2023-04-21 10:06:12 -07:00
|
|
|
mangled.SetValue(ConstString(func_name));
|
2018-02-09 05:31:28 +00:00
|
|
|
|
|
|
|
|
return mangled;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool SymbolFilePDB::DeclContextMatchesThisSymbolFile(
|
2020-02-17 19:25:52 +01:00
|
|
|
const lldb_private::CompilerDeclContext &decl_ctx) {
|
|
|
|
|
if (!decl_ctx.IsValid())
|
2018-02-09 05:31:28 +00:00
|
|
|
return true;
|
|
|
|
|
|
2020-02-17 19:25:52 +01:00
|
|
|
TypeSystem *decl_ctx_type_system = decl_ctx.GetTypeSystem();
|
2018-02-09 05:31:28 +00:00
|
|
|
if (!decl_ctx_type_system)
|
|
|
|
|
return false;
|
2019-07-30 22:12:34 +00:00
|
|
|
auto type_system_or_err = GetTypeSystemForLanguage(
|
2018-02-09 05:31:28 +00:00
|
|
|
decl_ctx_type_system->GetMinimumLanguage(nullptr));
|
2019-07-30 22:12:34 +00:00
|
|
|
if (auto err = type_system_or_err.takeError()) {
|
|
|
|
|
LLDB_LOG_ERROR(
|
2022-01-31 15:57:48 +01:00
|
|
|
GetLog(LLDBLog::Symbols), std::move(err),
|
2023-07-05 10:47:14 -07:00
|
|
|
"Unable to determine if DeclContext matches this symbol file: {0}");
|
2019-07-30 22:12:34 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2022-11-14 16:24:36 -08:00
|
|
|
if (decl_ctx_type_system == type_system_or_err->get())
|
2018-02-09 05:31:28 +00:00
|
|
|
return true; // The type systems match, return true
|
|
|
|
|
|
|
|
|
|
return false;
|
|
|
|
|
}
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
|
|
|
|
|
uint32_t SymbolFilePDB::GetCompilandId(const llvm::pdb::PDBSymbolData &data) {
|
|
|
|
|
static const auto pred_upper = [](uint32_t lhs, SecContribInfo rhs) {
|
|
|
|
|
return lhs < rhs.Offset;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
// Cache section contributions
|
|
|
|
|
if (m_sec_contribs.empty()) {
|
|
|
|
|
if (auto SecContribs = m_session_up->getSectionContribs()) {
|
|
|
|
|
while (auto SectionContrib = SecContribs->getNext()) {
|
|
|
|
|
auto comp_id = SectionContrib->getCompilandId();
|
|
|
|
|
if (!comp_id)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
auto sec = SectionContrib->getAddressSection();
|
|
|
|
|
auto &sec_cs = m_sec_contribs[sec];
|
|
|
|
|
|
|
|
|
|
auto offset = SectionContrib->getAddressOffset();
|
2022-09-03 11:17:38 -07:00
|
|
|
auto it = llvm::upper_bound(sec_cs, offset, pred_upper);
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
|
|
|
|
|
auto size = SectionContrib->getLength();
|
|
|
|
|
sec_cs.insert(it, {offset, size, comp_id});
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check by line number
|
|
|
|
|
if (auto Lines = data.getLineNumbers()) {
|
|
|
|
|
if (auto FirstLine = Lines->getNext())
|
|
|
|
|
return FirstLine->getCompilandId();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Retrieve section + offset
|
|
|
|
|
uint32_t DataSection = data.getAddressSection();
|
|
|
|
|
uint32_t DataOffset = data.getAddressOffset();
|
|
|
|
|
if (DataSection == 0) {
|
|
|
|
|
if (auto RVA = data.getRelativeVirtualAddress())
|
|
|
|
|
m_session_up->addressForRVA(RVA, DataSection, DataOffset);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (DataSection) {
|
|
|
|
|
// Search by section contributions
|
|
|
|
|
auto &sec_cs = m_sec_contribs[DataSection];
|
2022-09-03 11:17:38 -07:00
|
|
|
auto it = llvm::upper_bound(sec_cs, DataOffset, pred_upper);
|
[PDB] Improve performance of the PDB DIA plugin
Summary:
This patch improves performance of `SymbolFilePDB` on huge executables
in two ways:
- cache names of public symbols by address. When creating variables we are
trying to get a mangled name for each one, and in `GetMangledForPDBData`
we are enumerating all public symbols, which takes O(n) for each variable.
With the cache we can retrieve a mangled name in O(log(n));
- cache section contributions. When parsing variables for context we are
enumerating all variables and check if the current one is belonging
to the current compiland. So we are retrieving a compiland ID
for the variable. But in `PDBSymbolData::getCompilandId` for almost every
variable we are enumerating all section contributions to check if the variable
is belonging to it, and get a compiland ID from the section contribution
if so. It takes O(n) for each variable, but with caching it takes about
O(log(n)). I've placed the cache in `SymbolFilePDB` and have created
`GetCompilandId` there. It actually duplicates `PDBSymbolData::getCompilandId`
except for the cache part. Another option is to support caching
in `PDBSymbolData::getCompilandId` and to place cache in `DIASession`, but it
seems that the last one doesn't imply such functionality, because
it's a lightweight wrapper over DIA and whole its state is only a COM pointer
to the DIA session. Moreover, `PDBSymbolData::getCompilandId` is used only
inside of `SymbolFilePDB`, so I think that it's not a bad place to do such
things. With this patch `PDBSymbolData::getCompilandId` is not used at all.
This bottlenecks were found with profiling. I've discovered these on a simple
demo project of Unreal Engine (x86 executable ~72M, PDB ~82M).
This patch doesn't change external behavior of the plugin, so I think that
there's no need for additional testing (already existing tests should warn us
about regress, if any).
Reviewers: zturner, asmith, labath
Reviewed By: asmith
Subscribers: Hui, lldb-commits, stella.stamenova
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53375
llvm-svn: 345013
2018-10-23 08:29:17 +00:00
|
|
|
if (it != sec_cs.begin()) {
|
|
|
|
|
--it;
|
|
|
|
|
if (DataOffset < it->Offset + it->Size)
|
|
|
|
|
return it->CompilandId;
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Search in lexical tree
|
|
|
|
|
auto LexParentId = data.getLexicalParentId();
|
|
|
|
|
while (auto LexParent = m_session_up->getSymbolById(LexParentId)) {
|
|
|
|
|
if (LexParent->getSymTag() == PDB_SymType::Exe)
|
|
|
|
|
break;
|
|
|
|
|
if (LexParent->getSymTag() == PDB_SymType::Compiland)
|
|
|
|
|
return LexParentId;
|
|
|
|
|
LexParentId = LexParent->getRawSymbol().getLexicalParentId();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
}
|