|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6 |
|
| #
aa88161b |
| 19-Jun-2022 |
Kazu Hirata <[email protected]> |
[lldb] Use value_or instead of getValueOr (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2 |
|
| #
7b81192d |
| 20-Apr-2022 |
Jeffrey Tan <[email protected]> |
Introduce new symbol on-demand for debug info
This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant perfo
Introduce new symbol on-demand for debug info
This diff introduces a new symbol on-demand which skips loading a module's debug info unless explicitly asked on demand. This provides significant performance improvement for application with dynamic linking mode which has large number of modules. The feature can be turned on with: "settings set symbols.load-on-demand true"
The feature works by creating a new SymbolFileOnDemand class for each module which wraps the actual SymbolFIle subclass as member variable. By default, most virtual methods on SymbolFileOnDemand are skipped so that it looks like there is no debug info for that module. But once the module's debug info is explicitly requested to be enabled (in the conditions mentioned below) SymbolFileOnDemand will allow all methods to pass through and forward to the actual SymbolFile which would hydrate module's debug info on-demand.
In an internal benchmark, we are seeing more than 95% improvement for a 3000 modules application.
Currently we are providing several ways to on demand hydrate a module's debug info: * Source line breakpoint: matching in supported files * Stack trace: resolving symbol context for an address * Symbolic breakpoint: symbol table match guided promotion * Global variable: symbol table match guided promotion
In all above situations the module's debug info will be on-demand parsed and indexed.
Some follow-ups for this feature: * Add a command that allows users to load debug info explicitly while using a new or existing command when this feature is enabled * Add settings for "never load any of these executables in Symbols On Demand" that takes a list of globs * Add settings for "always load the the debug info for executables in Symbols On Demand" that takes a list of globs * Add a new column in "image list" that shows up by default when Symbols On Demand is enable to show the status for each shlib like "not enabled for this", "debug info off" and "debug info on" (with a single character to short string, not the ones I just typed)
Differential Revision: https://reviews.llvm.org/D121631
show more ...
|
|
Revision tags: llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2 |
|
| #
eb4c8608 |
| 19-Feb-2022 |
serge-sans-paille <[email protected]> |
Cleanup llvm/DebugInfo/PDB headers
accumulated preprocessed size: before: 1065515095 after: 1065629059
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differenti
Cleanup llvm/DebugInfo/PDB headers
accumulated preprocessed size: before: 1065515095 after: 1065629059
Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120195
show more ...
|
|
Revision tags: llvmorg-14.0.0-rc1 |
|
| #
c34698a8 |
| 03-Feb-2022 |
Pavel Labath <[email protected]> |
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging inf
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should.
After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
show more ...
|
|
Revision tags: llvmorg-15-init |
|
| #
a007a6d8 |
| 31-Jan-2022 |
Pavel Labath <[email protected]> |
[lldb] Convert "LLDB" log channel to the new API
|
|
Revision tags: llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
| #
b738a69a |
| 04-Nov-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] StringRef-ify the name parameter in CreateEnumerationType
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D113176
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
7177c595 |
| 12-Jul-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use ArrayRef in TypeSystemClang::SetFunctionParameters
The implementation converts the pointer/size pair anyway back to ArrayRef.
|
| #
fd2433e1 |
| 02-Jul-2021 |
Jonas Devlieghere <[email protected]> |
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html
Differential revision: https://reviews.llvm.org/D104041
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1 |
|
| #
ec28e43e |
| 11-May-2021 |
Augusto Noronha <[email protected]> |
Add null-pointer checks when accessing a TypeSystem's SymbolFile
A type system is not guaranteed to have a symbol file. This patch adds null-pointer checks so we don't crash when trying to access a
Add null-pointer checks when accessing a TypeSystem's SymbolFile
A type system is not guaranteed to have a symbol file. This patch adds null-pointer checks so we don't crash when trying to access a type system's symbol file.
Reviewed By: aprantl, teemperor
Differential Revision: https://reviews.llvm.org/D101539
show more ...
|
| #
1435f6b0 |
| 30-Apr-2021 |
Med Ismail Bennani <[email protected]> |
[lldb] Move and clean-up the Declaration class (NFC)
This patch moves the Declaration class from the Symbol library to the Core library. This will allow to use it in a more generic fashion and aims
[lldb] Move and clean-up the Declaration class (NFC)
This patch moves the Declaration class from the Symbol library to the Core library. This will allow to use it in a more generic fashion and aims to lower the dependency cycles when it comes to the linking.
The patch also does some cleaning up by making column information permanent and removing the LLDB_ENABLE_DECLARATION_COLUMNS directives.
Differential revision: https://reviews.llvm.org/D101556
Signed-off-by: Med Ismail Bennani <[email protected]>
show more ...
|
|
Revision tags: llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4 |
|
| #
0cb7e7ca |
| 17-Mar-2021 |
Vassil Vassilev <[email protected]> |
Make iteration over the DeclContext::lookup_result safe.
The idiom: ``` DeclContext::lookup_result R = DeclContext::lookup(Name); for (auto *D : R) {...} ```
is not safe when in the loop body we tr
Make iteration over the DeclContext::lookup_result safe.
The idiom: ``` DeclContext::lookup_result R = DeclContext::lookup(Name); for (auto *D : R) {...} ```
is not safe when in the loop body we trigger deserialization from an AST file. The deserialization can insert new declarations in the StoredDeclsList whose underlying type is a vector. When the vector decides to reallocate its storage the pointer we hold becomes invalid.
This patch replaces a SmallVector with an singly-linked list. The current approach stores a SmallVector<NamedDecl*, 4> which is around 8 pointers. The linked list is 3, 5, or 7. We do better in terms of memory usage for small cases (and worse in terms of locality -- the linked list entries won't be near each other, but will be near their corresponding declarations, and we were going to fetch those memory pages anyway). For larger cases: the vector uses a doubling strategy for reallocation, so will generally be between half-full and full. Let's say it's 75% full on average, so there's N * 4/3 + 4 pointers' worth of space allocated currently and will be 2N pointers with the linked list. So we break even when there are N=6 entries and slightly lose in terms of memory usage after that. We suspect that's still a win on average.
Thanks to @rsmith!
Differential revision: https://reviews.llvm.org/D91524
show more ...
|
|
Revision tags: llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2 |
|
| #
722247c8 |
| 17-Dec-2020 |
Raphael Isemann <[email protected]> |
[lldb] Unify the two CreateTypedef implementations in TypeSystemClang
To get LLDB one step closer to fulfil the software redundancy requirements of modern aircrafts, we apparently decided to have tw
[lldb] Unify the two CreateTypedef implementations in TypeSystemClang
To get LLDB one step closer to fulfil the software redundancy requirements of modern aircrafts, we apparently decided to have two separately maintained implementations of `CreateTypedef` in TypeSystemClang. Let's pass on the idea of an LLDB-powered jetliner and deleted one implementation.
On a more serious note: This function got duplicated a long time ago when the idea of CompilerType with a backing TypeSystemClang subclass happened (56939cb31061d24ae3d1fc62da38b57e78bb2556). One implementation was supposed to be called from CompilerType::CreateTypedef and the other has just always been around to create typedefs. By accident one of the implementations is only used by the PDB parser while the CompilerType::CreateTypedef backend is used by the rest of LLDB.
We also had some patches over the year that only fixed one of the two functions (D18099 for example only fixed up the CompilerType::CreateTypedef implementation). D51162 and D86140 both fixed the same missing `addDecl` call for one of the two implementations.
This patch: * deletes the `CreateTypedefType` function as its only used by the PDB parser and the `CreateTypedef` implementation is anyway needed as it's the backend implementation of CompilerType. * replaces the calls in the PDB parser by just calling the CompilerType wrapper. * moves the documentation to the remaining function. * moves the check for empty typedef names that was only in the deleted implementation to the other (I don't think this fixes anything as I believe all callers are already doing the same check).
I'll fix up the usual stuff (not using StringRef, not doing early exit) in a NFC follow-up.
This patch is not NFC as the PDB parser now calls the function that has the fix from D18099.
Reviewed By: labath, JDevlieghere
Differential Revision: https://reviews.llvm.org/D93382
show more ...
|
|
Revision tags: llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2 |
|
| #
cfb773c6 |
| 17-Aug-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use StringRef in CreateFunctionDeclaration/GetDeclarationName
CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is (only) used by CreateFunctionDeclaration so th
[lldb][NFC] Use StringRef in CreateFunctionDeclaration/GetDeclarationName
CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is (only) used by CreateFunctionDeclaration so that's why now also takes a StringRef.
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2 |
|
| #
895529cf |
| 25-Jun-2020 |
Aleksandr Urakov <[email protected]> |
[lldb][PDB] Constexpr static member values as AST literals
Summary: When evaluating an expression referencing a constexpr static member variable, an error is issued because the PDB does not specify
[lldb][PDB] Constexpr static member values as AST literals
Summary: When evaluating an expression referencing a constexpr static member variable, an error is issued because the PDB does not specify a symbol with an address that can be relocated against.
Rather than attempt to resolve the variable's value within the IR execution, the values of all constants can be looked up and incorporated into the AST of the record type as a literal, mirroring the original compiler AST.
This change applies to DIA and native PDB loaders.
Patch By: jackoalan
Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor
Reviewed By: aleksandr.urakov
Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D82160
show more ...
|
|
Revision tags: llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4 |
|
| #
143d507c |
| 04-Mar-2020 |
Adrian Prantl <[email protected]> |
Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags in DWARF. This patch recreates the Clang module hierarch
Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags in DWARF. This patch recreates the Clang module hierarchy in LLDB and 1;95;0csets the owning module information accordingly. My primary motivation is to facilitate looking up per-module APINotes for individual declarations, but this likely also has other applications.
This reapplies the previously reverted commit, but without support for ClassTemplateSpecializations, which I'm going to look into separately.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
show more ...
|
| #
32672b87 |
| 02-Apr-2020 |
Adrian Prantl <[email protected]> |
Revert "Preserve the owning module information from DWARF in the synthesized AST"
This reverts commit 4354dfbdf5c8510a7ddff10ae67a28e16cf7cc79 while investigating bot fallout.
|
| #
4354dfbd |
| 04-Mar-2020 |
Adrian Prantl <[email protected]> |
Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags in DWARF. This patch recreates the Clang module hierarch
Preserve the owning module information from DWARF in the synthesized AST
Types that came from a Clang module are nested in DW_TAG_module tags in DWARF. This patch recreates the Clang module hierarchy in LLDB and sets the owning module information accordingly. My primary motivation is to facilitate looking up per-module APINotes for individual declarations, but this likely also has other applications.
rdar://problem/59634380
Differential Revision: https://reviews.llvm.org/D75488
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc3 |
|
| #
8ffea27a |
| 18-Feb-2020 |
Raphael Isemann <[email protected]> |
[lldb] Refactor and test TypeSystemClang::GetEnumerationIntegerType
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
8be30215 |
| 29-Jan-2020 |
Alex Langford <[email protected]> |
[lldb] Move clang-based files out of Symbol
Summary: This change represents the move of ClangASTImporter, ClangASTMetadata, ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, and TypeSyst
[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
show more ...
|
| #
adcd0268 |
| 28-Jan-2020 |
Benjamin Kramer <[email protected]> |
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly m
Make llvm::StringRef to std::string conversions explicit.
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
show more ...
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[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 ----------------------------------------
[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
show more ...
|
| #
6e3b0cc2 |
| 23-Jan-2020 |
Raphael Isemann <[email protected]> |
[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 Type
[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
show more ...
|
|
Revision tags: llvmorg-11-init |
|
| #
b036f557 |
| 25-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb] Remove some calls to GetASTContext
GetASTContext is really expensive to call as it makes use of the global mapping from ASTContext to ClangASTContext. This replaces all calls where we already
[lldb] Remove some calls to GetASTContext
GetASTContext is really expensive to call as it makes use of the global mapping from ASTContext to ClangASTContext. This replaces all calls where we already have the ClangASTContext around and don't need to call GetASTContext again.
show more ...
|
| #
42ec584a |
| 23-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Make CompilerDeclContext construction type safe
The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly conver
[lldb][NFC] Make CompilerDeclContext construction type safe
The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly convert all pointers to clang::DeclContext*. This causes that we for example can't just pass a TranslationUnitDecl* to the constructor without first casting it to its parent class (as it inherits from both Decl and DeclContext so the void* pointer is actually a Decl*).
This patch introduces a utility function in the ClangASTContext which gets rid of the requirement to cast all pointers to clang::DeclContext. Also moves all constructor calls to use this function instead which is NFC (beside the change in DWARFASTParserClangTests.cpp).
show more ...
|
| #
f9f49d35 |
| 21-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Return a reference from ClangASTContext::getASTContext and remove dead nullptr checks
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a while t
[lldb][NFC] Return a reference from ClangASTContext::getASTContext and remove dead nullptr checks
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a while that the ASTContext is not a nullptr. This causes that we still have a lot of code that is doing nullptr checks on the result of getASTContext() which is all unreachable code.
This patch changes the return value to a reference to make it clear this can't be a nullptr and deletes all the nullptr checks.
show more ...
|