calls to commonly un-overridden methods into a function that checks whether
the method is overridden anywhere and if not directly dispatches to the
NSObject implementation.
That means if you do override any of these methods, "step-in" will not step
into your code, since we hit the wrapper function, which has no debug info,
and immediately step out again.
Add code to recognize these functions as "trampolines" and a thread plan that
will get us from the function to the user code, if overridden.
<rdar://problem/54404114>
Differential Revision: https://reviews.llvm.org/D73225
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
Summary:
I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like this:
```
CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1
```
From the log messages it's unclear what this ASTContext is. Is it the scratch context, the expression context, some decl vendor context or a context from a module?
The pointer value isn't helpful for anyone unless I'm in a debugger where I could inspect the memory at the address. But even with a debugger it's not easy to
figure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocation
from the file system usually means that this is the Objective-C decl vendor, a file name from multiple expressions is probably the scratch context, etc.).
This patch adds a name field to ClangASTContext instances that we can use to store a name which can be used for logging and debugging. With this
our log messages now look like this:
```
CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo
```
We can now also just print a ClangASTContext from the debugger and see a useful name in the `m_display_name` field, e.g.
```
m_display_name = "AST for /Users/user/test/main.o";
```
Reviewers: shafik, labath, JDevlieghere, mib
Reviewed By: shafik
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72391
AppleObjCRuntime is the main entry point to the plugin with the same
name. This is part of a greater refactoring to auto generate the
initializers. NFC.
Differential revision: https://reviews.llvm.org/D73121
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
LLDB frequently converts QualType to CompilerType. This is currently done like this:
result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
1. CompilerType's constructor takes a void* pointer so it isn't type safe.
2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
changing it is difficult (e.g., what if we want to just pass the type ptr and not the
1type_ptr | qual_flags1 to CompilerType).
This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.
It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
Instead of returning NamedDecls and then calling GetASTContext
to find back the ClangASTContext we used can just implement the
FindDecl variant that returns CompilerDecls (and implement the
other function by throwing away the ClangASTContext part of the
compiler decl).
This code actually needs a ClangASTContext but instead takes a
clang::ASTContext and then retrieves the original ClangASTContext
via the global map of ClangASTContexts. Let's change it so
that it takes a ClangASTContext which is simpler and faster.
ClangExternalASTSourceCommon's purpose is to store a map from
Decl*/Type* to ClangASTMetadata. Usually this data is accessed
via the ClangASTContext interface which then grabs the
current ExternalASTSource of its ASTContext, tries to cast it
to ClangExternalASTSourceCommon and then accesses the metadata
map. If the casting fails the setter does nothing and the getter
returns a nullptr as if there was no known metadata for a type/decl.
This system breaks as soon as any non-LLDB ExternalASTSource is added via
a multiplexer to our existing ExternalASTSource (in which case we suddenly
loose all out metadata as the casting always fails with an ExternalASTSource
that is not inheriting from ClangExternalASTSourceCommon).
This patch moves the metadata map to the ClangASTContext. This gets
rid of all the fragile casting, the requirement that every ExternalASTSource in
LLDB has to inherit from ClangExternalASTSourceCommon and simplifies
the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon
had no other purpose than storing metadata, this patch deletes this class
and replaces all uses with clang::ExternalASTSource.
No other code changes in this commit beside the AppleObjCDeclVendor which
was the only code that did not use the ClangASTContext interface but directly
accessed the ClangExternalASTSourceCommon.
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.
Summary:
As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup.
This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup
setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around
for now).
The motivation for this is that I don't think that the current approach of implementing modern-type-lookup
will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone
and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has
so far made the transition work much more complicated than it has to be.
A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization
in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly
the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring
and actually testing the existing code we have.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html
Reviewers: shafik, martong
Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71562
Target doesn't really need to know about ClangASTContext more than any
other TypeSystem. We can create a method ClangASTContext::GetScratch for
anything who needs a ClangASTContext specifically instead of just a
generic TypeSystem.
Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
Summary:
LLDB's ASTDumper is just a clone of Clang's ASTDumper but with some scary code and
some unrelated functionality (like dumping name/attributes of types). This removes LLDB's ASTDumper
and replaces its uses with the `ClangUtils::DumpDecl` method that just calls Clang's ASTDumper
and returns the result as a string.
The few uses where we just want a textual representation of a type (which will print their name/attributes but not
dump any AST) are now also in ClangUtil under a `ToString` name until we find a better home for them.
Reviewers: labath
Reviewed By: labath
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70663
Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.
Differential Revision: https://reviews.llvm.org/D69913
Performance issues lead to the libc++ std::function formatter to be disabled.
This change is the first of two changes that should address the performance issues and allow us to enable the formatter again.
In some cases we end up scanning the symbol table for the callable wrapped by std::function for those cases we will now cache the results and used the cache in subsequent look-ups. This still leaves a large cost for the initial lookup which will be addressed in the next change.
Differential Revision: https://reviews.llvm.org/D67111
Normally you shouldn't be able to have a process with an ItaniumABI plugin
that doesn't have this symbol. But if the loader crashes before loading
libc++abi.dylib (on MacOS), then the symbol might not be present. So we
should check before accessing the pointer.
There isn't a good way to write a test for this, but the change is obvious.
The field holding the "ro" will now be a union. If the low bit is set,
then it isn't an ro and it needs to be dereferenced once more to get to
it. If the low bit isn't set, then it is a proper class_ro_t
No dedicated test is needed as this code path will trigger when running
the existing Objective-C tests under a current version of the runtime.
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
Summary:
The SearchCallback has a bool parameter that we always set to false, we never use in any callback implementation and that also changes its name
from one file to the other (either `containing` and `complete`). It was added in the original LLDB check in, so there isn't any history what
this was supposed to be, so let's just remove it.
Reviewers: jingham, JDevlieghere, labath
Reviewed By: jingham, labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68696
llvm-svn: 374313
Testing whether a name is mangled or not is extremely cheap and can be
done by looking at the first two characters. Mangled knows how to do
it. On the flip side, many call sites that currently pass in an
is_mangled determination do not know how to correctly do it (for
example, they leave out Swift mangling prefixes).
This patch removes this entry point and just forced Mangled to
determine the mangledness of a string itself.
Differential Revision: https://reviews.llvm.org/D68674
llvm-svn: 374180
Link against clang-cpp dylib rather than split libs when
CLANG_LINK_CLANG_DYLIB is enabled.
Differential Revision: https://reviews.llvm.org/D68456
llvm-svn: 373734
In r368345 I accidentally introduced a regression that would
over-report the number of matches found by FindTypes if the
DeclContext Filter was hit.
This patch simply removes the size_t return parameter altogether —
it's not that useful.
rdar://problem/55500457
Differential Revision: https://reviews.llvm.org/D68169
llvm-svn: 373344
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
Summary:
This patch converts FileSystem::Open from this prototype:
Status
Open(File &File, const FileSpec &file_spec, ...);
to this one:
llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);
This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67996
llvm-svn: 373003
The StringRef should always be identical to the C string, so we
might as well just create the StringRef from the C-string. This
might be slightly slower until we implement the storage of ArgEntry
with a string instead of a std::unique_ptr<char[]>. Until then we
have to do the additional strlen on the C string to construct the
StringRef.
llvm-svn: 371842
A new SPI was added to the objc runtime to get class names without
any demangling; AppleObjCRuntimeV2::ParseClassInfoArray was using
the original prototype name but had not been updated for the final
name yet, so lldb was falling back to the old function and doing
extra work for classes that were demangled. This commit fixes that.
llvm-svn: 370152
Summary:
This removes DeclVendor's dependency on clang (and ClangASTContext).
DeclVendor has no need to know about specific TypeSystems.
Differential Revision: https://reviews.llvm.org/D66628
llvm-svn: 369735
While generating the Doxygen I noticed this lone namespace that has one
class and one function in it. This moves them into lldb_private.
llvm-svn: 369485
Summary:
This introduces a layer between DeclVendor and the currently implemented
DeclVendors (ClangModulesDeclVendor and AppleObjCDeclVendor). This
allows the removal of DeclVendor::GetImporterSource which is extremely
clang-specific, freeing up the interface to be more general.
A good follow up to this would be to remove the remaining instances of
clang in DeclVendor, either by moving things to ClangDeclVendor or by
using wrappers (e.g. CompilerDecl instead of clang::NamedDecl).
Differential Revision: https://reviews.llvm.org/D66451
llvm-svn: 369424
I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI
as an advantage and there is already constructor parameter to compile the
regex.
Differential Revision: https://reviews.llvm.org/D66392
llvm-svn: 369352
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.
Differential Revision: https://reviews.llvm.org/D66102
llvm-svn: 368741
Value::GetValueAsData() takes an undocumented parameter called
data_offset that is always 0.
Differential Revision: https://reviews.llvm.org/D65910
llvm-svn: 368330
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
Instead of having to write FileSpecList::Append(FileSpec(args)) you can
now call FileSpecList::EmplaceBack(args), similar to
std::vector<>::emplace_back.
llvm-svn: 366489
Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.
Reviewers: JDevlieghere, compnerd, jingham, clayborg
Subscribers: mgorny, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D64763
llvm-svn: 366148
Summary: This seems better suited to be in a plugin.
Reviewers: JDevlieghere, clayborg, jingham, compnerd, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64599
llvm-svn: 365951
