Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3 |
|
#
b852fb1e |
| 25-Oct-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Move ValueObject into its own library (NFC) (#113393)
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-
[lldb] Move ValueObject into its own library (NFC) (#113393)
ValueObject is part of lldbCore for historical reasons, but conceptually
it deserves to be its own library. This does introduce a (link-time) circular
dependency between lldbCore and lldbValueObject, which is unfortunate
but probably unavoidable because so many things in LLDB rely on
ValueObject. We already have cycles and these libraries are never built
as dylibs so while this doesn't improve the situation, it also doesn't
make things worse.
The header includes were updated with the following command:
```
find . -type f -exec sed -i.bak "s%include \"lldb/Core/ValueObject%include \"lldb/ValueObject/ValueObject%" '{}' \;
```
show more ...
|
Revision tags: 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 |
|
#
624ea68c |
| 08-Mar-2024 |
Adrian Prantl <adrian-prantl@users.noreply.github.com> |
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected
This is an NFC change that does no
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected
This is an NFC change that does not yet add any error handling or change any code to return any errors.
This is the second big change in the patch series started with https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
show more ...
|
#
300a39bd |
| 08-Mar-2024 |
Florian Mayer <fmayer@google.com> |
Revert "Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)"
This reverts commit 99118c809367d518ffe4de60c16da953744b68b9.
|
#
99118c80 |
| 08-Mar-2024 |
Adrian Prantl <adrian-prantl@users.noreply.github.com> |
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does
Change GetNumChildren()/CalculateNumChildren() methods return llvm::Expected (#84219)
Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected
This is an NFC change that does not yet add any error handling or change
any code to return any errors.
This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501
A follow-up PR will wire up error handling.
show more ...
|
Revision tags: llvmorg-18.1.1 |
|
#
e710523e |
| 05-Mar-2024 |
Adrian Prantl <aprantl@apple.com> |
Change GetChildAtIndex to take a uint32_t
|
#
3d7c5b80 |
| 29-Feb-2024 |
Adrian Prantl <aprantl@apple.com> |
Change the return type of SyntheticFrontend::CalculateNumChildren to int32_t
This way it is consistent with ValueObject and TypeSystem.
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
#
d7fb94b6 |
| 08-Feb-2024 |
Michael Buch <michaelbuch12@gmail.com> |
[lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return an enum (#80167)
This patch changes the return value of
`SyntheticChildrenFrontend::Update` to a scoped enum that aims to
[lldb][TypeSynthetic][NFC] Make SyntheticChildrenFrontend::Update() return an enum (#80167)
This patch changes the return value of
`SyntheticChildrenFrontend::Update` to a scoped enum that aims to
describe what the return value means.
show more ...
|
Revision tags: 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 |
|
#
9faf8b51 |
| 21-Sep-2023 |
jeffreytan81 <jeffreytan@fb.com> |
Lazy deference underlying object for shared/weak/unique_ptr synthetic… (#67069)
We noticed some performance issue while in lldb-vscode for grabing the
name of the SBValue. Profiling shows SBValue::
Lazy deference underlying object for shared/weak/unique_ptr synthetic… (#67069)
We noticed some performance issue while in lldb-vscode for grabing the
name of the SBValue. Profiling shows SBValue::GetName() can cause
synthetic children provider of shared/unique_ptr to deference underlying
object and complete it type.
This patch lazily moves the dereference from synthetic child provider's
Update() method to GetChildAtIndex() so that SBValue::GetName() won't
trigger the slow code path.
Here is the culprit slow code path:
```
...
frame #59: 0x00007ff4102e0660 liblldb.so.15`SymbolFileDWARF::CompleteType(this=<unavailable>, compiler_type=0x00007ffdd9829450) at SymbolFileDWARF.cpp:1567:25 [opt]
...
frame #67: 0x00007ff40fdf9bd4 liblldb.so.15`lldb_private::ValueObject::Dereference(this=0x0000022bb5dfe980, error=0x00007ffdd9829970) at ValueObject.cpp:2672:41 [opt]
frame #68: 0x00007ff41011bb0a liblldb.so.15`(anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::Update(this=0x000002298fb94380) at LibStdcpp.cpp:403:40 [opt]
frame #69: 0x00007ff41011af9a liblldb.so.15`lldb_private::formatters::LibStdcppSharedPtrSyntheticFrontEndCreator(lldb_private::CXXSyntheticChildren*, std::shared_ptr<lldb_private::ValueObject>) [inlined] (anonymous namespace)::LibStdcppSharedPtrSyntheticFrontEnd::LibStdcppSharedPtrSyntheticFrontEnd(this=0x000002298fb94380, valobj_sp=<unavailable>) at LibStdcpp.cpp:371:5 [opt]
...
frame #78: 0x00007ff40fdf6e42 liblldb.so.15`lldb_private::ValueObject::CalculateSyntheticValue(this=0x000002296c66a500) at ValueObject.cpp:1836:27 [opt]
frame #79: 0x00007ff40fdf1939 liblldb.so.15`lldb_private::ValueObject::GetSyntheticValue(this=<unavailable>) at ValueObject.cpp:1867:3 [opt]
frame #80: 0x00007ff40fc89008 liblldb.so.15`ValueImpl::GetSP(this=0x0000022c71b90de0, stop_locker=0x00007ffdd9829d00, lock=0x00007ffdd9829d08, error=0x00007ffdd9829d18) at SBValue.cpp:141:46 [opt]
frame #81: 0x00007ff40fc7d82a liblldb.so.15`lldb::SBValue::GetSP(ValueLocker&) const [inlined] ValueLocker::GetLockedSP(this=0x00007ffdd9829d00, in_value=<unavailable>) at SBValue.cpp:208:21 [opt]
frame #82: 0x00007ff40fc7d817 liblldb.so.15`lldb::SBValue::GetSP(this=0x00007ffdd9829d90, locker=0x00007ffdd9829d00) const at SBValue.cpp:1047:17 [opt]
frame #83: 0x00007ff40fc7da6f liblldb.so.15`lldb::SBValue::GetName(this=0x00007ffdd9829d90) at SBValue.cpp:294:32 [opt]
...
```
Differential Revision: https://reviews.llvm.org/D159542
show more ...
|
Revision tags: 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 |
|
#
a1a74f7c |
| 29-May-2023 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Default can_create to true in GetChildAtIndex (NFC)
Existing callers of `GetChildAtIndex` pass true for can_create. This change makes true the default value, callers don't have to pass an opa
[lldb] Default can_create to true in GetChildAtIndex (NFC)
Existing callers of `GetChildAtIndex` pass true for can_create. This change makes true the default value, callers don't have to pass an opaque true.
See also D151966 for the same change to `GetChildMemberWithName`.
Differential Revision: https://reviews.llvm.org/D152031
show more ...
|
#
7d4fcd41 |
| 29-May-2023 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Default can_create to true in GetChildMemberWithName (NFC)
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`. This change makes `true` the default value
[lldb] Default can_create to true in GetChildMemberWithName (NFC)
It turns out all existing callers of `GetChildMemberWithName` pass true for `can_create`. This change makes `true` the default value, callers don't have to pass an opaque true.
Differential Revision: https://reviews.llvm.org/D151966
show more ...
|
#
00e52cc4 |
| 28-May-2023 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Take StringRef names in GetChildAtNamePath (NFC)
Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef` values instead of `ConstString`.
Differential Revision: ht
[lldb] Take StringRef names in GetChildAtNamePath (NFC)
Following D151810, this changes `GetChildAtNamePath` to take a path of `StringRef` values instead of `ConstString`.
Differential Revision: https://reviews.llvm.org/D151813
show more ...
|
#
cb463c34 |
| 27-May-2023 |
Dave Lee <davelee.com@gmail.com> |
[lldb] Take StringRef name in GetChildMemberWithName (NFC)
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function take a `StringRef` instead, which alleviates the nee
[lldb] Take StringRef name in GetChildMemberWithName (NFC)
`GetChildMemberWithName` does not need a `ConstString`. This change makes the function take a `StringRef` instead, which alleviates the need for callers to construct a `ConstString`. I don't expect this change to improve performance, only ergonomics.
This is in support of Alex's effort to replace `ConstString` where appropriate.
There are related `ValueObject` functions that can also be changed, if this is accepted.
Differential Revision: https://reviews.llvm.org/D151615
show more ...
|
#
44bb442f |
| 23-May-2023 |
Michael Buch <michaelbuch12@gmail.com> |
[lldb][DataFormatter] Add dereference support to libstdcpp std::shared_ptr formatter
This mimicks the implementation of the libstdcpp std::unique_ptr formatter.
This has been attempted several year
[lldb][DataFormatter] Add dereference support to libstdcpp std::shared_ptr formatter
This mimicks the implementation of the libstdcpp std::unique_ptr formatter.
This has been attempted several years ago in `0789722d85cf1f1fdbe2ffb2245ea0ba034a9f94` but was reverted in `e7dd3972094c2f2fb42dc9d4d5344e54a431e2ce`.
The difference to the original patch is that we now maintain a `$$dereference$$` member and we only store weak pointers to the other children inside the synthetic frontend. This is what the libc++ formatters do to prevent the recursion mentioned in the revert commit.
show more ...
|
Revision tags: llvmorg-16.0.4 |
|
#
25159ee3 |
| 10-May-2023 |
Jeffrey Tan <jeffreytan@fb.com> |
Fix libstdc++ data formatter for reference/pointer to std::string
This patch fixes libstdc++ data formatter for reference/pointer to std::string. The failure testcases are added which succeed with t
Fix libstdc++ data formatter for reference/pointer to std::string
This patch fixes libstdc++ data formatter for reference/pointer to std::string. The failure testcases are added which succeed with the patch.
Differential Revision: https://reviews.llvm.org/D150313
show more ...
|
Revision tags: 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 |
|
#
2fe83274 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
f190ce62 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optiona
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
2f4a66ee |
| 09-Sep-2022 |
Adrian Prantl <aprantl@apple.com> |
Adapt LLDB dataformatters for libcxx change D129386
Differential Revision: https://reviews.llvm.org/D133618
|
Revision tags: 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, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
28c878ae |
| 14-Mar-2022 |
Shafik Yaghmour <syaghmour@apple.com> |
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in cl
[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121481
show more ...
|
Revision tags: llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1 |
|
#
4c56f734 |
| 03-Nov-2021 |
Pavel Labath <pavel@labath.sk> |
[lldb] (Partially) enable formatting of utf strings before the program is started
The StringPrinter class was using a Process instance to read memory. This automatically prevented it from working be
[lldb] (Partially) enable formatting of utf strings before the program is started
The StringPrinter class was using a Process instance to read memory. This automatically prevented it from working before starting the program.
This patch changes the class to use the Target object for reading memory, as targets are always available. This required moving ReadStringFromMemory from Process to Target.
This is sufficient to make frame/target variable work, but further changes are necessary for the expression evaluator. Preliminary analysis indicates the failures are due to the expression result ValueObjects failing to provide an address, presumably because we're operating on file addresses before starting. I haven't looked into what would it take to make that work.
Differential Revision: https://reviews.llvm.org/D113098
show more ...
|
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, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, 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, 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, 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, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6 |
|
#
7b244258 |
| 19-Mar-2020 |
Raphael Isemann <teemperor@gmail.com> |
Reland [lldb] Fix string summary of an empty NSPathStore2
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix the Debian tests).
Summary: Printing a summary for an empty NSPath
Reland [lldb] Fix string summary of an empty NSPathStore2
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix the Debian tests).
Summary: Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).
It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.
This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly was the original purpose of this magic value).
Reviewers: aprantl, JDevlieghere, shafik
Reviewed By: aprantl
Subscribers: christof, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68010
show more ...
|
Revision tags: llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
#
8be30215 |
| 29-Jan-2020 |
Alex Langford <apl@fb.com> |
[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 ...
|
#
80814287 |
| 24-Jan-2020 |
Raphael Isemann <teemperor@gmail.com> |
[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 <teemperor@gmail.com> |
[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, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
#
05cfdb0e |
| 26-Apr-2019 |
Raphael Isemann <teemperor@gmail.com> |
Allow direct comparison of ConstString against StringRef
Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn
Allow direct comparison of ConstString against StringRef
Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison.
However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ```
Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings.
I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString.
This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers.
This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator.
Reviewers: #lldb, JDevlieghere, espindola, amccarth
Reviewed By: JDevlieghere, amccarth
Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D60667
llvm-svn: 359281
show more ...
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
#
0e4c4821 |
| 06-Mar-2019 |
Adrian Prantl <aprantl@apple.com> |
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, s
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
show more ...
|