| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
methods. The Clang dump is now much more verbose,
but when somebody types "target modules lookup -t"
that is typically what they're looking for.
llvm-svn: 145892
|
|
|
|
| |
llvm-svn: 145884
|
|
|
|
| |
llvm-svn: 145840
|
|
|
|
|
|
|
|
|
| |
and CompleteTagDeclarationDefinition() on Objective-C
interfaces populated by SymbolFileSymtab::FindTypes(),
we should mark the interface as forward-declared when
we create it.
llvm-svn: 145825
|
|
|
|
| |
llvm-svn: 145814
|
|
|
|
|
|
|
|
|
|
|
|
| |
and fixes we did. Now that objective C classes are represented by symbols with
their own type, there were a few more places in the objective C code that needed
to be fixed when searching for dynamic types.
Cleaned up the objective C runtime plug-in a bit to not keep having to create
constant strings and make one less memory access when we find an "isa" in the
objective C cache.
llvm-svn: 145799
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
add them to a fast lookup map. lldb_private::Symtab now export the following
public typedefs:
namespace lldb_private {
class Symtab {
typedef std::vector<uint32_t> IndexCollection;
typedef UniqueCStringMap<uint32_t> NameToIndexMap;
};
}
Clients can then find symbols by name and or type and end up with a
Symtab::IndexCollection that is filled with indexes. These indexes can then
be put into a name to index lookup map and control if the mangled and
demangled names get added to the map:
bool add_demangled = true;
bool add_mangled = true;
Symtab::NameToIndexMap name_to_index;
symtab->AppendSymbolNamesToMap (indexes, add_demangled, add_mangled, name_to_index).
This can be repeated as many times as needed to get a lookup table that
you are happy with, and then this can be sorted:
name_to_index.Sort();
Now name lookups can be done using a subset of the symbols you extracted from
the symbol table. This is currently being used to extract objective C types
from object files when there is no debug info in SymbolFileSymtab.
Cleaned up how the objective C types were being vended to be more efficient
and fixed some errors in the regular expression that was being used.
llvm-svn: 145777
|
|
|
|
|
|
|
|
|
|
|
| |
class. The thing with Objective C classes is the debug info might have a
definition that isn't just a forward decl, but it is incomplete. So we need to
look and see if we can find the complete definition and avoid recursing a lot
due to the fact that our accelerator tables will have many versions of the
type, but only one complete one. We might not also have the complete type
and we need to deal with this correctly.
llvm-svn: 145759
|
|
|
|
|
|
|
|
|
|
|
|
| |
Objective-C, making symbol lookups for various raw
Objective-C symbols work correctly. The IR interpreter
makes these lookups because Clang has emitted raw
symbol references for ivars and classes.
Also improved performance in SymbolFiles, caching the
result of asking for SymbolFile abilities.
llvm-svn: 145758
|
|
|
|
|
|
| |
still need to write the test case file.
llvm-svn: 145756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for all our external AST sources that lets us associate
arbitrary flags with the types we put into the AST
contexts. Also added an API on ClangASTContext that
allows access to these flags given only an ASTContext
and a type.
Because we don't have access to RTTI, and because at
some point in the future we might encounter external
AST sources that we didn't make (so they don't subclass
ClangExternalASTSourceCommon) I added a magic number
that we check before doing anything else, so that we
can catch that problem as soon as it appears.
llvm-svn: 145748
|
|
|
|
| |
llvm-svn: 145746
|
|
|
|
|
|
|
|
| |
object file can correctly make these symbols which will abstract us from the
file format and ABI and we can then ask for the objective C class symbol for
a class and find out which object file it was defined in.
llvm-svn: 145744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
address from
the function it is being asked to step through, so that even if we get the trampoline
target wrong (for instance) we will still not lose control.
The other fix here is to tighten up the handling of the case where the current plan
doesn't explain the stop, but a plan above us does. In that case, if the plan that
does explain the stop says it is done, we need to clean up the plans below it and
continue on with our processing.
llvm-svn: 145740
|
|
|
|
| |
llvm-svn: 145735
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed an issue where if we have the DWARF equivalent of:
struct foo;
class foo { ... };
Or vice versa, we wouldn't be able to find the complete type. Since many
compilers allow forward declarations to have struct and definitions to have
class, we need to be able to deal with both cases. This commit fixes this in
the DWARF parser.
llvm-svn: 145733
|
|
|
|
|
|
| |
the session info
llvm-svn: 145732
|
|
|
|
|
|
| |
Fixed an issue that could cause an infinite recursion when using "type filter".
llvm-svn: 145720
|
|
|
|
|
|
|
|
|
|
| |
to use ConstStrings. The const char*s were assumed to
be from ConstStrings before, but since storing a full-on
ConstString is no more expensive than storing a const
char* it makes better sense to enforce uniqueness with
the type checker.
llvm-svn: 145688
|
|
|
|
|
|
|
|
| |
Objective-C symbols. The methods aren't used yet if
there is a competing definition in the DWARF; I will
resolve that next.
llvm-svn: 145675
|
|
|
|
|
|
|
| |
previous binaries that link against this for a few builds to make sure we
can continue to run against previous binaries.
llvm-svn: 145668
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed templates with NonTypeTemplateParmDecl objects. For example:
template <unsigned N>
....
This fixes SmallVector and all of the other classes that have template params
that are non types.
llvm-svn: 145667
|
|
|
|
| |
llvm-svn: 145660
|
|
|
|
|
|
|
|
| |
will allow us to represent a process/thread ID using a pointer for the OS
plug-ins where they might want to represent the process or thread ID using
the address of the process or thread structure.
llvm-svn: 145644
|
|
|
|
|
|
|
|
|
|
| |
in the face of failures to import types, since blithely
passing on NULL types can sometimes lead to trouble.
Also eliminated a use of getAs and replaced it with
dyn_cast, which is more robust.
llvm-svn: 145628
|
|
|
|
| |
llvm-svn: 145625
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
enhancements. With these enhancements, the return values
of Objective-C methods with unknown return types can be
implicitly cast to id for the purpose of making method
calls.
So what would have required this:
(int)[(id)[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
can now be written as:
(int)[[ClassWithNoDebugInfo methodReturningObject] methodReturningInt]
llvm-svn: 145567
|
|
|
|
|
|
|
| |
Avoid a crash for the new DW_OP_stack_value and DW_OP_implicit_value opcodes
that was due to an assertion.
llvm-svn: 145564
|
|
|
|
| |
llvm-svn: 145561
|
|
|
|
|
|
| |
into the CrashReporter string first.
llvm-svn: 145558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
robust:
- Now a client can specify what kind of symbols
are needed; notably, this allows looking up
Objective-C class symbols specifically.
- In the class of symbols being looked up, if
one is non-NULL and others are NULL, LLDB now
prefers the non-NULL one.
llvm-svn: 145554
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangASTSource::~ClangASTSource() was calling
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext();
which had the side effect of deleting this very ClangASTSource instance. Not good.
Change it to
// We are in the process of destruction, don't create clang ast context on demand
// by passing false to Target::GetScratchClangASTContext(create_on_demand).
ClangASTContext *scratch_clang_ast_context = m_target->GetScratchClangASTContext(false);
The Target::GetScratchClangASTContext(bool create_on_demand=true) has a new signature.
llvm-svn: 145537
|
|
|
|
| |
llvm-svn: 145528
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to find Objective-C class types by looking in the
symbol tables for the individual object files.
I did this as follows:
- I added code to SymbolFileSymtab that vends
Clang types for symbols matching the pattern
"_OBJC_CLASS_$_NSMyClassName," making them
appear as Objective-C classes. This only occurs
in modules that do not have debug information,
since otherwise SymbolFileDWARF would be in
charge of looking up types.
- I made a new SymbolVendor subclass for the
Apple Objective-C runtime that is in charge of
making global lookups of Objective-C types. It
currently just sends out type lookup requests to
the appropriate SymbolFiles, but in the future we
will probably extend it to query the runtime more
completely.
I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.
llvm-svn: 145526
|
|
|
|
| |
llvm-svn: 145516
|
|
|
|
|
|
| |
a symbol, were weren't showing the "<module>`<symbol>" header.
llvm-svn: 145511
|
|
|
|
|
|
| |
Fix the breakage by properly setting the result status before returning.
llvm-svn: 145507
|
|
|
|
| |
llvm-svn: 145472
|
|
|
|
|
|
| |
objective C DWARF emitted by clang.
llvm-svn: 145471
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix wrong test logic in test_modules_search_paths(). Add additional exercising of 'target modules search-paths list/query".
There is a reproducible crash if 'target modules search-paths clear' is exercised during test teardown.
So we currently comment out the stmt as follows:
# Add teardown hook to clear image-search-paths after the test.
# rdar://problem/10501020
# Uncomment the following to reproduce 10501020.
#self.addTearDownHook(lambda: self.runCmd("target modules search-paths clear"))
llvm-svn: 145466
|
|
|
|
| |
llvm-svn: 145459
|
|
|
|
|
|
| |
Find the one true objective C type definition if there is one within a module.
llvm-svn: 145457
|
|
|
|
|
|
| |
ASTDumper.h.
llvm-svn: 145446
|
|
|
|
|
|
|
|
| |
ValueObjects when creating variables referring to
live data rather than constructing
ValueObjectConstResults.
llvm-svn: 145437
|
|
|
|
| |
llvm-svn: 145435
|
|
|
|
| |
llvm-svn: 145434
|
|
|
|
|
|
| |
implementation of the linux platform.
llvm-svn: 145433
|
|
|
|
| |
llvm-svn: 145417
|
|
|
|
|
|
|
|
| |
Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.
llvm-svn: 145371
|
|
|
|
|
|
|
|
|
|
| |
as well as attached a new priority description as to why and when you would
want to implement each packet.
Also documented the additions we have made to the stop reply packet and why
the extra information is necessary.
llvm-svn: 145357
|