parser was creating malformed resuls. When the
location of a variable is computed by reading a
register and adding an offset, we shouldn't say
that the variable's value is located in that
register. This was confusing the expression
parser when trying to read a variable captured
by a block.
llvm-svn: 147668
Be better at detecting when DWARF changes and handle this more
gracefully than asserting and exiting.
Also fixed up a bunch of system calls that weren't properly checking
for EINTR.
llvm-svn: 147559
Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.
llvm-svn: 147157
parser has hitherto been an implementation waiting
for a use. I have now tied the '-o' option for
the expression command -- which indicates that the
result is an Objective-C object and needs to be
printed -- to the ExpressionParser, which
communicates the desired type to Clang.
Now, if the result of an expression is determined
by an Objective-C method call for which there is
no type information, that result is implicitly
cast to id if and only if the -o option is passed
to the expression command. (Otherwise if there
is no explicit cast Clang will issue an error.
This behavior is identical to what happened before
r146756.)
Also added a testcase for -o enabled and disabled.
llvm-svn: 147099
"id" from being found by the parser as an
externally-defined type. Before, "id" would
sometimes make it through if it was defined in
a namespace, but this sometimes caused
confusion, for example when it conflicted with
std::locale::id.
llvm-svn: 146891
valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider
Patch from Enrico Granata:
The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.
The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.
llvm-svn: 146768
we handle Objective-C method calls. Currently,
LLDB treats the result of an Objective-C method
as unknown if the type information doesn't have
the method's signature. Now Clang can cast the
result to id if it isn't explicitly cast.
I also added a test case for this, as well as a
fix for a type import problem that this feature
exposed.
llvm-svn: 146756
the expression parser to locate instances where
dyn_cast<>() and isa<>() are used on types, and
replace them with getAs<>() as appropriate.
The difference is that dyn_cast<>() and isa<>()
are essentially LLVM/Clang's equivalent of RTTI
-- that is, they try to downcast the object and
return NULL if they cannot -- but getAs<>() can
traverse typedefs to perform a semantic cast.
llvm-svn: 146537
validates the "self," "this," and "_cmd" pointers
that get passed into expressions. It used to check
them aggressively for validity before allowing the
expression to run as an object method; now, this
functionality is gated by a bool and off by default.
Now the default is that when LLDB is stopped in a
method of a class, code entered using "expr" will
always masquerade as an instance method. If for
some reason "self," "this," or "_cmd" is unavailable
it will be reported as NULL. This may cause the
expression to crash if it relies on those pointers,
but for example getting the addresses of ivars will
now work as the user would expect.
llvm-svn: 146465
- Even if a frame isn't present, we always try
to use FindGlobalVariable to find variables.
Instead of using frame->TrackGlobalVariable()
to promote the VariableSP into a ValueObject,
we now simply use ValueObjectVariable.
- When requesting the value of a variable, we
allow returning of the "live version" of the
variable -- that is, the variable in the
target instead of a pointer to its freeze
dried version in LLDB -- even if there is no
process present.
llvm-svn: 146315
in the context in which it was originally found, the
expression parser now goes hunting for it in all modules
(in the appropriate namespace, if applicable). This means
that forward-declared types that exist in another shared
library will now be resolved correctly.
Added a test case to cover this. The test case also tests
"frame variable," which does not have this functionality
yet.
llvm-svn: 146204
pointer to make the result of an expression. LLDB now
dumps the ivars of the Objective-C object and all of
its parents. This just required fixing a bug where we
didn't distinguish between Objective-C object pointers
and regular C-style pointers.
Also added a testcase to verify that this continues to
work.
llvm-svn: 146164
symbols. Now we find the correct method.
Unfortunately we don't get the superclass from the
runtime yet so the method doesn't import correctly
(and I added a check to make sure that doesn't hurt
us) but once we get that information right we will
report methods correctly to the parser as well.
Getting superclass information requires a common AST
context for all Objective-C runtime information,
meaning that the superclass and the subclass are in
the same AST context in all cases. That is the next
thing that needs to be done here.
llvm-svn: 146089
from symbols more accessible, I have added a second
map to the ClangASTImporter: the ObjCInterfaceMetaMap.
This map keeps track of all type definitions found for
a particular Objective-C interface, allowing the
ClangASTSource to refer to all possible sources when
looking for method definitions.
There is a bug in lookup that I still need to figure out,
but after that we should be able to report full method
information for Objective-C classes shown in symbols.
Also fixed some errors I ran into when enabling the maps
for the persistent type store. The persistent type store
previously did not use the ClangASTImporter to import
types, instead using ASTImporters that got allocated each
time a type needed copying. To support the requirements
of the persistent type store -- namely, that types must be
copied, completed, and then completely severed from their
origin in the parser's AST context (which will go away) --
I added a new function called DeportType which severs all
these connections.
llvm-svn: 145914
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
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
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
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
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
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
management of what allocations remain after an
expression finishes executing. This saves around
2.5KiB per expression for simple expressions.
llvm-svn: 145342
several patches. These patches fix a problem
where templated types were not being completed the
first time they were used, and fix a variety of
minor issues I discovered while fixing that problem.
One of the previous local patches was resolved in
the most recent Clang, so I removed it. The others
will be removed in due course.
llvm-svn: 144984
to allow variables in the persistent variable store to know
how to complete themselves from debug information. That
fixes a variety of bugs during dematerialization of
expression results and also makes persistent variable and
result variables ($foo, $4, ...) more useful.
I have also added logging improvements that make it much
easier to figure out how types are moving from place to
place, and made some checking a little more aggressive.
The commit includes patches to Clang which are currently being
integrated into Clang proper; once these fixes are in Clang
top-of-tree, these patches will be removed. The patches don't
fix API; rather, they fix some internal bugs in Clang's
ASTImporter that were exposed when LLDB was moving types from
place to place multiple times.
llvm-svn: 144969
rather than individually on behalf of each
ASTContext. This allows the ASTImporter to know
about all containers of types, which will let it
be smarter about forwarding information about
type origins. That means that the following
sequence of steps will be possible (after a few
more changes):
- Import a type from a Module's ASTContext into
an expression parser ASTContext, tracking its
origin information -- this works now.
- Because the result of the expression uses that
type, import it from the expression parser
ASTContext into the Target's scratch AST
context, forwarding the origin information --
this needs to be added.
- For a later expression that uses the result,
import the type from the Target's scratch AST
context, still forwarding origin information
-- this also needs to be added.
- Use the intact origin information to complete
the type as needed -- this works now if the
origin information is present.
To this end, I made the following changes:
- ASTImporter top-level copy functions now
require both a source and a destination AST
context parameter.
- The ASTImporter now knows how to purge
records related to an ASTContext that is
going away.
- The Target now owns and creates the ASTImporter
whenever the main executable changes or (in the
absence of a main executable) on demand.
llvm-svn: 144802
types. First, I added handling for the memset intrinsic
in the IR, which is used to zero out the returned struct.
Second, I fixed the object-checking instrumentation
to objc_msgSend_stret, and generally tightened up how
the object-checking functions get inserted.
llvm-svn: 144741
of problems with Objective-C object completion. To go
along with the LLVM/Clang-side fixes, we have a variety
of Objective-C improvements.
Fixes include:
- It is now possible to run expressions when stopped in
an Objective-C class method and have "self" act just
like "self" would act in the class method itself (i.e.,
[self classMethod] works without casting the return
type if debug info is present). To accomplish this,
the expression masquerades as a class method added by
a category.
- Objective-C objects can now provide methods and
properties and methods to Clang on demand (i.e., the
ASTImporter sets hasExternalVisibleDecls on Objective-C
interface objects).
- Objective-C built-in types, which had long been a bone
of contention (should we be using "id"? "id*"?), are
now fetched correctly using accessor functions on
ClangASTContext. We inhibit searches for them in the
debug information.
There are also a variety of logging fixes, and I made two
changes to the test suite:
- Enabled a test case for Objective-C properties in the
current translation unit.
- Added a test case for calling Objective-C class methods
when stopped in a class method.
llvm-svn: 144607
This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.
The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.
While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
llvm-svn: 144489
interfaces. This allows us to pull in Objective-C
method types on demand, which is also now implemented.
Also added a minor fix to prevent multiple-definition
errors for "Class" and "id".
llvm-svn: 144405
lookups for Objective-C methods by selector.
Right now all it does is print log information.
Also improved the logging for imported TagDecls
to indicate whether or not the definition for
the imported TagDecl is complete.
llvm-svn: 144203
which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++. This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.
llvm-svn: 144042
