Summary: SymbolFileDWARF now creates VarDecl and BlockDecl and adds them to the Decl tree. Then, in ClangExpressionDeclMap it uses the Decl tree to search for a variable. This fixes lots of variable scoping problems.
Reviewers: sivachandra, chaoren, spyffe, clayborg
Subscribers: tberghammer, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D12658
llvm-svn: 247746
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
Summary:
When lldb is processing a location containing DW_OP_piece, the result is being
stored in the 'pieces' variable. The location is popped from the 'stack' variable.
So this check to see that 'stack' is not empty was invalid and caused the pieces
after the first to not get processed.
I am working on an architecture which has 16-bit and 8-bit registers. So this
problem was quite easy to see. But I was able to re-produce this issue on x86
too with long long variable and compiling woth -m32. It resulted in following
location list.
00000014 08048496 080484b5 (DW_OP_reg6 (esi); DW_OP_piece: 4; DW_OP_reg7 (edi); DW_OP_piece: 4)
and lldb was only showing the contents of first register when I evaluated the
variable as it does not process the 2nd piece due to this check.
Reviewers: clayborg, aprantl
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12674
llvm-svn: 247124
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible
methods, I've done the same for ExpressionVariable. The main documentation for
how to do this is in TypeSystem.h, so I've simply referred to that.
llvm-svn: 247085
This will keep our code cleaner and it removes the need for intrusive additions to TypeSystem like:
class TypeSystem
{
virtual ClangASTContext *
AsClangASTContext() = 0;
}
As you can now just use the llvm::dyn_cast and other casts.
llvm-svn: 247041
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
These are 2 new value currently in experimental status used when split
debug info is enabled.
Differential revision: http://reviews.llvm.org/D12238
llvm-svn: 245931
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
The right thing to do here would be to give the ASTConsumer to the
CompilerInstance so it can set things up for us, but we can't do that
because we don't own it. So instead just initialize it ourselves.
llvm-svn: 245397
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
We don't need to do the fancy dance with checking whether the iterator
represents a #define -- in fact, that's the wrong thing to do. The thing to do
is check whether the highest-priority module that did something to the module
#defined or #undefd it. If it #defined it, then the MacroInfo* will be non-NULL
and we're good to go.
llvm-svn: 241651
Recently lldb_private::Symbol was changed so the old code:
Address &Symbol::GetAddress();
Is now:
Address Symbol::GetAddress();
And the Address object that is returned will be invalid for non-address based symbols. When we have re-exported symbols this code would now fail:
const Address sym_address = sym_ctx.symbol->GetAddress();
if (!sym_address.IsValid())
continue;
symbol_load_addr = sym_ctx.symbol->ResolveCallableAddress(*target_sp);
if (symbol_load_addr == LLDB_INVALID_ADDRESS)
{
symbol_load_addr = sym_address.GetLoadAddress(target_sp.get());
}
It used to return an Address reference to the value of the re-exported symbol that contained no section and a zero value for Address.m_offset (since the original symbol in the symbol table had a value of zero). When a reference was returned, this meant the "sym_address.IsValid()" would return true because the Address.m_offset was not LLDB_INVALID_ADDRESS, it was zero. This was working by mistake.
The Symbol::ResolveCallableAddress(...) actually checks for reexported symbols and whole bunch of other cases and resolves the address correctly, so we should let it do its thing and not cut it off before it can resolve the address with the "if (!sym_address.IsValid()) continue;".
llvm-svn: 241282
The new names clarify that the members have to do with the execution
context and not the language. For example, m_cplusplus was renamed to
m_in_cplusplus_method.
llvm-svn: 241132
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
it an extern "C" function instead of a C++ function
so that Clang doesn't emit a mangled function reference.
Also removed the hack in ClangExpressionDeclMap that
works around this.
llvm-svn: 238476
expr_options = lldb.SBExpressionOptions()
expr_options.SetPrefix('''
struct Foo {
int a;
int b;
int c;
}
'''
expr_result = frame.EvaluateExpression ("Foo foo = { 1, 2, 3}; foo", expr_options)
This fixed a current issue with ptr_refs, cstr_refs and malloc_info so that they can work. If expressions define their own types and then return expression results that use those types, those types get copied into the target's AST context so they persist and the expression results can be still printed and used in future expressions. Code was added to the expression parser to copy the context in which types are defined if they are used as the expression results. So in the case of types defined by expressions, they get defined in a lldb_expr function and that function and _all_ of its statements get copied. Many types of statements are not supported in this copy (array subscript, lambdas, etc) so this causes expressions to fail as they can't copy the result types. To work around this issue I have added code that allows expressions to specify an expression specific prefix. Then when you evaluate the expression you can pass the "expr_options" and have types that can be correctly copied out into the target. I added this as a way to work around an issue, but I also think it is nice to be allowed to specify an expression prefix that can be reused by many expressions, so this feature is very useful.
<rdar://problem/21130675>
llvm-svn: 238365
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
(including inline functions) from modules in the
expression parser. We now have to retain a reference
to the code generator in ClangExpressionDeclMap so
that any imported function bodies can be appropriately
sent to that code generator.
<rdar://problem/19883002>
llvm-svn: 236297
global convenience expression prefix. Also ensured
that if macros are defined by the modules we don't
try to redefine them. Finally cleaned up a bit of
code while I was in there.
<rdar://problem/20756642>
llvm-svn: 236266
module-loading support for the expression parser.
- It adds support for auto-loading modules referred
to by a compile unit. These references are
currently in the form of empty translation units.
This functionality is gated by the setting
target.auto-import-clang-modules (boolean) = false
- It improves and corrects support for loading
macros from modules, currently by textually
pasting all #defines into the user's expression.
The improvements center around including only those
modules that are relevant to the current context -
hand-loaded modules and the modules that are imported
from the current compile unit.
- It adds an "opt-in" mechanism for all of this
functionality. Modules have to be explicitly
imported (via @import) or auto-loaded (by enabling
the above setting) to enable any of this
functionality.
It also adds support to the compile unit and symbol
file code to deal with empty translation units that
indicate module imports, and plumbs this through to
the CompileUnit interface.
Finally, it makes the following changes to the test
suite:
- It adds a testcase that verifies that modules are
automatically loaded when the appropriate setting
is enabled (lang/objc/modules-auto-import); and
- It modifies lanb/objc/modules-incomplete to test
the case where a module #undefs something that is
#defined in another module.
<rdar://problem/20299554>
llvm-svn: 235313
all the macros from the modules the user has loaded.
These macros are currently imported textually into
the expression's source code, which turns out not to
impose the horrific string processing overhead that
I thought it would, but I still plan to look into
performance improvements.
Also modified TestCModules to test that this works.
llvm-svn: 234922
relocations. We used to do GEP on a pointer to
the result type, which is wrong. We should be doing
GEP on a pointer to char, which allows us to offset
correctly.
This fixes the C modules testcase, so it's no longer
ExpectFail.
llvm-svn: 234918
Summary:
This fixes an issue with GCC generated binaries wherein an expression
with method invocations on std::string variables was failing. Such use
cases are tested in TestSTL (albeit, in a test marked with
@unittest2.expectedFailure because of other reasons).
The reason for this particular failure with GCC is that the generated
DWARF for std::basic_string<...> is incomplete, which makes clang not
to use the alternate mangling scheme. GCC correctly generates the name
of basic_string<...>:
DW_AT_name "basic_string<char, std::char_traits<char>, std::allocator<char> >"
It also lists the template parameters of basic_string correctly:
DW_TAG_template_type_parameter
DW_AT_name "_CharT"
DW_AT_type <0x0000009c>
DW_TAG_template_type_parameter
DW_AT_name "_Traits"
DW_AT_type <0x00000609>
DW_TAG_template_type_parameter
DW_AT_name "_Alloc"
DW_AT_type <0x000007fb>
However, it does not list the template parameters of std::char_traits<>.
This makes Clang feel (while parsing the expression) that the string
variable is not actually a basic_string instance, and consequently does
not use the alternate mangling scheme.
Test Plan:
dotest.py -C gcc -p TestSTL
-- See it go past the "for" loop expression successfully.
Reviewers: clayborg, spyffe
Reviewed By: clayborg, spyffe
Subscribers: tberghammer, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D8846
llvm-svn: 234522
Summary:
If a struct type S has a member T that has a member that is a function that
returns a typedef of S* the respective field would be duplicated, which caused
an assert down the line in RecordLayoutBuilder. This patch adds a check that
removes the possibility of trying to resolve the same type twice within the
same callstack.
This commit also adds unit tests for these failures.
Fixes https://llvm.org/bugs/show_bug.cgi?id=20486.
Patch by Cristian Hancila.
Test Plan: Run unit tests.
Reviewers: clayborg spyffe
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8561
llvm-svn: 234441
in a session would be silently ignored by the compiler
because the compiler looked at its SourceLocation and
decided it had already handled it.
Also updated the relevant test case.
<rdar://problem/20315447>
llvm-svn: 234330
This used to be the case for "printf" before a function prototype was added to the builtin expression prefix file. This fix makes sure that if we get a mangled name that we don't find in the current target, that we only fall back to looking up function by basename if the function isn't contained in a namespace or class (no decl context).
llvm-svn: 234178
verifying that the types from that module don't
override types from DWARF. Also added a target setting
to LLDB so we can tell Clang where to look for these
local modules.
<rdar://problem/18805055>
llvm-svn: 234016
A char can have signed and unsigned encoding but previously lldb always
assumed it is signed. This CL adds a logic to detect the encoding of
'char' types based on the default encoding on the target architecture.
It fixes variable printing and expression evaluation on architectures
where 'char' is signed by default.
Differential revision: http://reviews.llvm.org/D8636
llvm-svn: 233682
Since ClangASTSource::layoutRecordType() was overriding a virtual
function in the base, this was inadvertently causing a new method
to be introduced rather than an override. To fix this all method
signatures are changed back to taking DenseMaps, and the `override`
keyword is added to make sure this type of error doesn't happen
again.
To keep the original fix intact, which is that fields and bases
must be added in offset order, the ImportOffsetMap() function
now copies the DenseMap into a vector and then sorts the vector
on the value type (e.g. the offset) before iterating over the
sorted vector and inserting the items.
llvm-svn: 233099
Prior to this patch, we would try to synthesize class types by
iterating over a DenseMap of FieldDecls and adding each one to
a CXXRecordDecl. Since a DenseMap doesn't provide a deterministic
ordering of the elements, this would not add the fields in
FieldOffset order, but rather in some random order determined by
the memory layout of the DenseMap.
This patch fixes the issue by changing DenseMaps to vectors. The
ability to lookup a value in the DenseMap was hardly being used,
and where it is sufficient to do a vector lookup.
Differential Revision: http://reviews.llvm.org/D8512
llvm-svn: 233090
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
The issue can happen if you strip your main executable and then run an expression and it would fail to find the stripped symbol and it would then not be able to make the function call. The issue was fixed by doing our normal FindFunctions call.
<rdar://problem/20072750>
llvm-svn: 231667
This is a temporary fix until a more comprehensive fix can be made for finding functions that we call in expressions.
We find "NSLog" in ClangExpressionDeclMap::FindExternalVisibleDecls() in after a call to target->GetImages().FindFunctions(...). Note that there are two symbols: NSLog from CFNetwork which is not external, and NSLog from Foundation which _is_ external. We do something with the external symbol with:
if (extern_symbol)
{
AddOneFunction (context, NULL, extern_symbol, current_id);
context.m_found.function = true;
}
Then later we try to lookup the _Z5NSLogP8NSStringz name and we don't find it so we call ClangExpressionDeclMap::GetFunctionAddress() with "_Z5NSLogP8NSStringz" as the name and the sc_list_size is zero at the "if" statement at line 568 because we don't find the mangled name and we extract the basename "NSLog" and call:
FindCodeSymbolInContext(ConstString(basename), m_parser_vars->m_sym_ctx, sc_list);
sc_list_size = sc_list.GetSize();
and we get a list size of two again, and we proceed to search for the symbol again, this time ignoring the external vs non-external-ness of the symbols that we find. This fix ensures we prioritize the external symbol until we get a real fix from Sean Callanan when he gets back to make sure we don't do multiple lookups for the same symbol we already resolved.
<rdar://problem/19879282>
llvm-svn: 231420
operator in addition to the vendor-extension DW_OP_GNU_push_tls_address.
clang on PS4 and Darwin will be emitting the standard opcode
as of r231286 via http://reviews.llvm.org/D8018
Behavior of this standard opcode is the same as
DW_OP_GNU_push_tls_address.
<rdar://problem/20043195>
llvm-svn: 231342
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
This is part of a larger effort to reduce header file footprints.
Combined, these patches reduce the build time of LLDB locally by
over 30%. However, they touch many files and make many changes,
so will be submitted in small incremental pieces.
Reviewed By: Greg Clayton
Differential Revision: http://reviews.llvm.org/D8022
llvm-svn: 231097
const, there was never a need for lookup_const_result. Now that vestigal
type is gone, so switch LLDB to lookup_result and to use the
DeclContextLookupResult rather than the Const variant.
llvm-svn: 230126
There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.
Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.
llvm-svn: 228892
Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.
The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.
These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).
llvm-svn: 228207
This was causing code that opened multiple targets to try and get a path to debugserver from the GDB remote communication class, and it would get the LLDB path and some instances would return empty strings and it would cause debugserver to not be found.
<rdar://problem/18756927>
llvm-svn: 227935
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
it does call, and implementing it so that we once again look up external symbols in the JIT.
Also juked the error reporting from the JIT a little bit.
This resolves:
http://llvm.org/bugs/show_bug.cgi?id=22314
llvm-svn: 227217
inferring the function signature. This works well where the ABI doesn't
distinguish between variadic and fixed argument lists, but on arm64 the
calling conventions differ. The default assumption works for fixed argument
lists, but variadic functions require explicit prototypes to be called.
By far the most common case where this is an issue is when attempting to use
printf(). This change augments the default expression prefix to include a
working variadic prototype for the function.
<rdar://problem/19024779>
llvm-svn: 226744
MS ABI guard variables end with @4IA, so this patch teaches the
interpreter about that. Additionally, there was an issue with
TurnGuardLoadIntoZero which was causing some guard uses of a
variable to be missed. This fixes that by calling
Instruction::replaceAllUsesWith() instead of trying to replicate
that function.
llvm-svn: 225547
Objective-C types and enums in modules. We now have
a three-stage fallback when looking for methods and
properties: first the DWARF, second the modules, third
the runtime.
<rdar://problem/18782288>
llvm-svn: 223939
Fix PR21802 by correcting the destruction order of
`ClangExpressionParser` and `IRExecutionUnit` in `ClangFunction`. The
former has hooks into the latter -- i.e., `clang::CGDebugInfo` points at
the `LLVMContext` -- so it needs to be torn down first.
This was exposed by r223802 in LLVM, which started doing work in the
`CGDebugInfo` teardown.
llvm-svn: 223916
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
support to LLDB. It includes the following:
- Changed DeclVendor to TypeVendor.
- Made the ObjCLanguageRuntime provide a DeclVendor
rather than a TypeVendor.
- Changed the consumers of TypeVendors to use
DeclVendors instead.
- Provided a few convenience functions on
ClangASTContext to make that easier.
llvm-svn: 223433
being asked about symbols it doesn't know about. If
it's asked about a symbol by mangled name and it finds
nothing, then it will try again with the demangled
base name.
llvm-svn: 221660
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
This setting contains the following:
A list containing all the arguments to be passed to the expression parser compiler.
This change also ensures quoted arguments are handled appropriately.
See http://reviews.llvm.org/D5472 for more details.
Change by Tong Shen.
llvm-svn: 219169
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
This continues the effort to get Host code moved over to HostInfo,
and removes many more instances of preprocessor defines along the
way.
llvm-svn: 216195
This patch creates a HostInfo class, a static class used to answer
basic queries about the host platform. As part of this change,
some functionality is moved from Host to HostInfo, and relevant
fixups are performed in the rest of the codebase.
This is part of a larger effort to isolate more code in the Host
layer into platform-specific groups, to make it easier to make
platform specific changes for a particular Host without breaking
other hosts.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4963
llvm-svn: 215992
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_fbreg(M) DW_OP_piece(8)
DW_OP_fbreg(N) DW_OP_piece(4) DW_OP_piece(8)
The first grabs 4 bytes from FP+N followed by 8 bytes from FP+M, the second grabs 4 bytes from FP+N followed by zero filling 8 bytes which are unavailable. Of course regiters are stuff supported:
DW_OP_reg3 DW_OP_piece(4) DW_OP_reg8 DW_OP_piece(8)
The fix does the following:
1 - don't push the full piece value onto the stack, keep it on the side
2 - fill zeros for DW_OP_piece(N) opcodes that have nothing on the stack (instead of previously consuming the full piece that was pushed onto the stack)
3 - simplify the logic
<rdar://problem/16930524>
llvm-svn: 214415
See the following llvm change for details:
r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines
AArch64: remove arm64 triple enumerator.
This change fixes build breaks on Linux and MacOSX lldb.
llvm-svn: 213755
result variable and use in in "Process::LoadImage" so that,
for instance, "process load" doesn't increment the return
variable number.
llvm-svn: 213440
Fixes include:
- Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx"
- Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID.
- Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs
- Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map
- Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified.
llvm-svn: 212783
The current strategy for host allocation is to choose a random
address and attempt to allocate there, eventually failing if the
allocation cannot be satisfied.
The C standard only guarantees that RAND_MAX >= 32767, so for
platforms that use a very small RAND_MAX allocations will fail
with very high probability. On such platforms (Windows is one),
you can reproduce this trivially by running lldb, typing "expr (3)"
and then hitting enter you see a failure. Failures generally
happen with a frequency of about 1 failure every 5 evaluations.
There is no good reason that allocations need to look like "real"
pointers, so this patch changes the allocation scheme to simply
jump straight to the end and grab a free chunk of memory.
Reviewed By: Sean Callanan
Differential Revision: http://reviews.llvm.org/D4300
llvm-svn: 212630
off_t is a type which is used for file offsets. Even more
specifically, it is only used by a limited number of C APIs that
deal with files. Any usage of off_t where the variable is not
intended to be used with one of these APIs is a bug, by definition.
This patch corrects some easy mis-uses of off_t, generally by
converting them to lldb::offset_t, but sometimes by using other
types such as size_t, when appropriate.
The use of off_t to represent these offsets has worked fine in
practice on linux-y platforms, since we used _FILE_OFFSET_64 to
guarantee that off_t was a uint64. On Windows, however,
_FILE_OFFSET_64 is unrecognized, and off_t will always be 32-bit.
So the usage of off_t on Windows actually leads to legitimate bugs.
Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D4358
llvm-svn: 212192
This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
Previously, only the starting locations of the candidate interval
and the existing interval were compared. To correctly detect
range intersections, it is necessary to compare the entire range
of both intervals against each other.
Reviewed by: scallanan
Differential Revision: http://reviews.llvm.org/D4286
llvm-svn: 211726
The patch is as is with the functionality left disabled for apple vendors because of performance regressions. If this is enabled it ends up searching for symbols in all shared libraries that are loadeded.
llvm-svn: 211638
Address the 'variable set but not used' warning from GCC. In some cases a few
additional calls were removed where there should be no visible side effects of
the calls (i.e. should not effect any cached state).
llvm-svn: 210879
of the symbol itself rather than forcing clients to do
it. This simplifies the logic for the expression
parser a great deal.
<rdar://problem/16935324>
llvm-svn: 209494
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
values of variables in the Materializer.
The Materializer should not write the variable
back if its new value is the *same* as the old
value, not if the new value is *different*.
<rdar://problem/16712205>
llvm-svn: 207148
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
if they didn't change, just like it does for
registers. This makes life easier for kernel
debugging and any other situation where values
are read-only.
<rdar://problem/16367795>
llvm-svn: 204764
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
The standard JIT has been discarded in favour of MCJIT. USE_STANDARD_JIT is no
longer defined. Furthermore, the execution engine is now built in
IRExecutionUnit. Simply remove inclusion of both JIT headers.
llvm-svn: 204112
erroneously completing Objective-C classes sourced
from the Objective-C runtime without checking if
there was an authoritative version in the debug
information.
<rdar://problem/16065049>
llvm-svn: 203600
What was use_iterator is now user_iterator. Also switch to range-based
APIs, as in Clang r203365.
(This part of the change was missed in r203463)
Differential Revision: http://llvm-reviews.chandlerc.com/D3030
llvm-svn: 203475
read during materialization. First of all, report
if we can't read the data for some reason. Second,
consult the ValueObject's error and report that if
there's some problem.
<rdar://problem/16074201>
llvm-svn: 202552
to a variable. This helps people figure out what
happened if they tried to do something to the variable
and it didn't work because we gave it the default type
of void*.
llvm-svn: 201737
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
As done in other DW_OP_* cases, return an error if the stack is empty
rather than eventually crashing elsewhere. Encountered on big-endian
MIPS, where LLVM bugs currently result in invalid .debug_loc data.
llvm-svn: 199110
materialize a variable in a register correctly
if the variable is a pointer. This fixes a
regression introduced by my commit of Oct. 22nd
(r193191).
llvm-svn: 198718
of Objective-C classes are completed, and that
variables of Objective-C types have their types
completed when the variables are reported.
This fixes a long-standing issue where ivars did
not show up correctly on 32-bit OS X.
<rdar://problem/12184093>
llvm-svn: 197775
specify a pointer size until code gen. So we just
make all our pointer-sized integer literals 64-bit.
That doesn't seem to hurt anything.
llvm-svn: 197774
llvm::ArrayRef of arguments rather than taking
a fixed number of possibly-NULL pointers to
arguments.
Also changed ClangFunction::GetThreadPlanToCallFunction
to take the address of the argument struct by value
instead of by reference, since it doesn't actually
modify the value passed into it.
llvm-svn: 194232
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
Fixed a case where on darwin, after recent compiler changes a few months ago, we could not execute dlopen() in an expression, or use "process load".
The issue was some compiler option default values changed. We now override these settings to get the old behavior back.
llvm-svn: 194012
Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments.
The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen.
llvm-svn: 194009
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.
Fixes bug #17551.
Patch by "/dev/humancontroller"
llvm-svn: 193832
Fixed the expression parser to be able to iterate across all function name matches that it finds when it is looking for the address of a function that the IR is looking for. Also taught it to deal with reexported symbols.
llvm-svn: 193716
Fixed an issue with reexported symbols on MacOSX by adding support for symbols re-exporting symbols. There is now a new symbol type eSymbolTypeReExported which contains a new name for the re-exported symbol and the new shared library. These symbols are only used when a symbol is re-exported as a symbol under a different name.
Modified the expression parser to be able to deal with finding the re-exported symbols and track down the actual symbol it refers to.
llvm-svn: 193101
To make this work this patch extends LLDB to:
- Explicitly track the link_map address for each module. This is effectively the module handle, not sure why it wasn't already being stored off anywhere. As an extension later, it would be nice if someone were to add support for printing this as part of the modules list.
- Allow reading the per-thread data pointer via ptrace. I have added support for Linux here. I'll be happy to add support for FreeBSD once this is reviewed. OS X does not appear to have __thread variables, so maybe we don't need it there. Windows support should eventually be workable along the same lines.
- Make DWARF expressions track which module they originated from.
- Add support for the DW_OP_GNU_push_tls_address DWARF opcode, as generated by gcc and recent versions of clang. Earlier versions of clang (such as 3.2, which is default on Ubuntu right now) do not generate TLS debug info correctly so can not be supported here.
- Understand the format of the pthread DTV block. This is where it gets tricky. We have three basic options here:
1) Call "dlinfo" or "__tls_get_addr" on the inferior and ask it directly. However this won't work on core dumps, and generally speaking it's not a good idea for the debugger to call functions itself, as it has the potential to not work depending on the state of the target.
2) Use libthread_db. This is what GDB does. However this option requires having a version of libthread_db on the host cross-compiled for each potential target. This places a large burden on the user, and would make it very hard to cross-debug from Windows to Linux, for example. Trying to build a library intended exclusively for one OS on a different one is not pleasant. GDB sidesteps the problem and asks the user to figure it out.
3) Parse the DTV structure ourselves. On initial inspection this seems to be a bad option, as the DTV structure (the format used by the runtime to manage TLS data) is not in fact a kernel data structure, it is implemented entirely in useerland in libc. Therefore the layout of it's fields are version and OS dependent, and are not standardized.
However, it turns out not to be such a problem. All OSes use basically the same algorithm (a per-module lookup table) as detailed in Ulrich Drepper's TLS ELF ABI document, so we can easily write code to decode it ourselves. The only question therefore is the exact field layouts required. Happily, the implementors of libpthread expose the structure of the DTV via metadata exported as symbols from the .so itself, designed exactly for this kind of thing. So this patch simply reads that metadata in, and re-implements libthread_db's algorithm itself. We thereby get cross-platform TLS lookup without either requiring third-party libraries, while still being independent of the version of libpthread being used.
Test case included.
llvm-svn: 192922
to be explicit, to prevent horrid things like
std::string a = ConstString("foo")
from taking the path ConstString -> bool -> char
-> std::string.
This fixes, among other things, ClangFunction.
<rdar://problem/15137989>
llvm-svn: 191934
have a certain name, not just the first. This
is useful if a class method and an instance
method have the same name.
<rdar://problem/14872081>
llvm-svn: 190008
Testing shows it works for at least trivial cases, while the
USE_STANDARD_JIT case does not even work for those. Thus, don't define
USE_STANDARD_JIT on FreeBSD.
I've left the #if block choosing the appropriate #include in case it's
useful for testing.
llvm-svn: 189611
live beyont parsing. This is important because
all the ClangASTImporter::Minions for a parser's
ASTContext are cleared when ClangExpressionDeclMap
is deleted.
This resolves many hard-to-reproduce crashes,
especially ones involving breakpoint conditions.
<rdar://problem/14775391>
llvm-svn: 189080
the extra check introduces 22 new test failures with the LLDB clang buildbot.
Note that the unhandled DWARF_OP codes in DWARFExpression::Evaluate don't cause test failures if the check is ignored.
llvm-svn: 187480
list have a shared pointer back to their DisassemblerLLVMC. This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now. I'll go back and fix this
for real when I have time to do so.
<rdar://problem/14581918>
llvm-svn: 187473
in LLDB that load the canonical frame address rather than a location list.
- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!
TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).
- Also adds some comments to DWARFCallFrameInfo whenever I got confused.
llvm-svn: 187361
If we are replacing a function with the nobuiltin attribute, it may be called
with the builtin attribute on call sites. Remove any such attributes since it's
illegal to have a builtin call to something other than a nobuiltin function.
This fixes the current buildbot breakage (where LLDB crashes on
"expression new foo(42)").
llvm-svn: 186990
delete a constant after we replaced it with a
dynamically-computed value. Also ensured that we
replace all users of the constant if there are
multiple ones. Added a testcase.
<rdar://problem/14379043>
llvm-svn: 186363
write to registers if they were modified in the
expression. This eliminates spurious errors if
the register can't be written to but the
expression didn't write to it anyway.
Also improved error handling for the materializer
to make "couldn't materialize struct" errors more
informative.
<rdar://problem/14322579>
llvm-svn: 186228
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.
Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)
llvm-svn: 185990
been suitable for preparing a single IR function
for operation in the target. However, using blocks
and lambdas creates other IR functions that also
need to be processed.
I have audited IRForTarget to make it process
multiple functions. Where IRForTarget would add
new instructions at the beginning of the main
expression function, it now adds them on-demand
in the function where they are needed. This is
enabled by a system of FunctionValueCaches, which
invoke a lambda to create or derive the values as
needed, or report the result of that lambda if it
has already been called for the given function.
<rdar://problem/14180236>
llvm-svn: 185224
has more than one function with a body. This
prevents declarations e.g. of blocks from being
passed to the IRInterpreter; they must pass
through to the JIT.
<rdar://problem/14180236>
llvm-svn: 185057
correctly. We have been getting lucky since most
expressions generate only one section (or the first
code section contains all the code), but sometimes
it actually matters.
<rdar://problem/14180236>
llvm-svn: 185054
bother checking if a region is safe to use. In
cases where regions need to be synthesized rather
than properly allocated, the memory reads required
to determine whether the area is used are
- insufficient, because intermediate locations
could be in use, and
- unsafe, because on some platforms reading from
memory can trigger events.
All this only makes a difference on platforms
where memory allocation in the target is impossible.
Behavior on platforms where it is possible should
stay the same.
<rdar://problem/14023970>
llvm-svn: 185046
dematerialization of registers that caused
conditional breakpoint expressions not to
work properly. Also added a testcase.
<rdar://problem/14129252>
llvm-svn: 184451
- Implemented the SExt instruction, and
- eliminated redundant codepaths for constant
handling.
Added test cases.
<rdar://problem/13244258>
<rdar://problem/13955820>
llvm-svn: 183344
live as long as they needed to. This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.
To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression. Hand-declared persistent
variables do this now.
<rdar://problem/13956311>
llvm-svn: 182528
Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression.
llvm-svn: 182066
regions that aren't actually allocated in the
process. This cache is used by the expression
parser if the underlying process doesn't support
memory allocation, to avoid needless repeated
searches for unused address ranges.
Also fixed a silly bug in IRMemoryMap where it
would continue searching even after it found a
valid region.
<rdar://problem/13866629>
llvm-svn: 182028
to the DeclContext. This fulfils the contract that
we make with Clang by returning ELR_AlreadyLoaded.
This is a little aggressive in that it does not allow
the ASTImporter to import the child decls with any
lexical parent other than the Decl that reported them
as children.
<rdar://problem/13517713>
llvm-svn: 181498
support operands with vector types, it now reports
that it cannot interpret expressions that use
vector types. They get sent to the JIT instead.
<rdar://problem/13733651>
llvm-svn: 180899
mostly related to management of the stack frame
for the interpreter.
- First, if the expression can be interpreted,
allocate the stack frame in the target process
(to make sure pointers are valid) but only
read/write to the copy in the host's memory.
- Second, keep the memory allocations for the
stack frame and the materialized struct as
member variables of ClangUserExpression. This
avoids memory allocations and deallocations
each time the expression runs.
<rdar://problem/13043685>
llvm-svn: 180664
interpreter. They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.
Also updated the #includes for IRInterpreter
accordingly.
llvm-svn: 180565
not find multiple functions with the same name but
different types. Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.
Also added a test case.
<rdar://problem/11367837>
llvm-svn: 180167
and persistent variables so that they are not
treated as remaining in the target process (i.e.,
having live data) when the process does not allow
persistent allocations (e.g., when there is no
process or in the case of kernel core files).
llvm-svn: 179919
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
Previously, the options for a breakopint or its
locations stored only the text of the breakpoint
condition (ironically, they used ClangUserExpression
as a glorified std::string) and, each time the condition
had to be evaluated in the StopInfo code, the expression
parser would be invoked via a static method to parse and
then execute the expression.
I made several changes here:
- Each breakpoint location now has its own
ClangUserExpressionSP containing a version of
the breakpoint expression compiled for that exact
location.
- Whenever the breakpoint is hit, the breakpoint
condition expression is simply re-run to determine
whether to stop.
- If the process changes (e.g., it's re-run) or
the source code of the expression changes (we use
a hash so as to avoid doing string comparisons)
the ClangUserExpressionSP is re-generated.
This should improve performance of breakpoint
conditions significantly, and takes advantage of
the recent expression re-use work.
llvm-svn: 179838
and made attempts to allocate memory in the process
fall back to FindSpace and just allocate memory on
the host (but with real-looking pointers, hence
FindSpace) if the process doesn't allow allocation.
This allows expressions to run on processes that don't
support allocation, like core files.
This introduces an extremely rare potential problem:
If all of the following are true:
- The Process doesn't support allocation;
- the user writes an expression that refers to an
address that does not yet map to anything, or is
dynamically generated (e.g., the result of calling
a function); and
- the randomly-selected address for the static data
for that specific expression runs into the
address the user was expecting to work with;
then dereferencing the pointer later results
in the user seeing something unexpected. This is
unlikely but possible; as a future piece of work,
we should have processes be able to hint to the
expression parser where it can allocate temporary data
of this kind.
llvm-svn: 179827
expressions.
Previously, ClangUserExpression assumed that if
there was a constant result for an expression
then it could be determined during parsing. In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap)
was present. This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run. Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.
I have rewritten the IRInterpreter to be
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see. This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be
present.
Materialization, interpretation, and dematerialization
are now all independent of parsing. This means that
in theory we can parse expressions once and run them
many times. I have three outstanding tasks before
shutting this down:
- First, I will ensure that all of this works with
core files. Core files have a Process but do not
allow allocating memory, which currently confuses
materialization.
- Second, I will make expression breakpoint
conditions remember their ClangUserExpression and
re-use it.
- Third, I will tear out all the redundant code
(for example, materialization logic in
ClangExpressionDeclMap) that is no longer used.
While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.
This should be fixed.
llvm-svn: 179801
will be gone soon!) that lets it interpret a function
using just an llvm::Module, an llvm::Function, and a
MemoryMap.
Also added an API to IRExecutionUnit to get at its
llvm::Function, so that the IRInterpreter can work
with it.
llvm-svn: 179704
a ClangExpressionDeclMap. Any functions that
require value resolution etc. fail if the
ClangExpressionDeclMap isn't present - which is
exactly what is desired.
llvm-svn: 179695
IRMemoryMap rather than through its own memory
abstraction. This considerably simplifies the
code, and makes it possible to run the
IRInterpreter multiple times on an already-parsed
expression in the absence of a ClangExpressionDeclMap.
Changes include:
- ClangExpressionDeclMap's interface methods
for the IRInterpreter now take IRMemoryMap
arguments. They are not long for this world,
however, since the IRInterpreter will soon be
working with materialized variables.
- As mentioned above, removed the Memory class
from the IR interpreter altogether. It had a
few functions that remain useful, such as
keeping track of Values that have been placed
in memory, so I moved those into methods on
InterpreterStackFrame.
- Changed IRInterpreter to work with lldb::addr_t
rather than Memory::Region as its primary
currency.
- Fixed a bug in the IRMemoryMap where it did not
report correct address byte size and byte order
if no process was present, because it was using
Target::GetDefaultArchitecture() rather than
Target::GetArchitecture().
- Made IRMemoryMap methods clear the Errors they
receive before running. Having to do this by
hand is just annoying.
The testsuite seems happy with these changes, but
please let me know if you see problems (especially
in use cases without a process).
llvm-svn: 179675
Materializer for all expressions that need to
run in the target. This includes the following
changes:
- Removed a bunch of (de-)materialization code
from ClangExpressionDeclMap and assumed the
presence of a Materializer where we previously
had a fallback.
- Ensured that an IRMemoryMap is passed into
ClangExpressionDeclMap::Materialize().
- Fixed object ownership on LLVMContext; it is
now owned by the IRExecutionUnit, since the
Module and the ExecutionEngine both depend on
its existence.
- Fixed a few bugs in IRMemoryMap and the
Materializer that showed up during testing.
llvm-svn: 179649
- If an allocation is mirrored between the host
and the process, update the host's version
before returning a DataExtractor pointing to
it.
- If anyone attempts to access memory in a
process/target that does not have a corresponding
allocation, try accessing the memory directly
before erroring out.
llvm-svn: 179561
for variables in the new Materializer. This is
much easier now that the ValueObject API is solid.
I still have to implement reading bytes into a
ValueObject, but committing what I have so far.
This code is not yet used, so there will be fixes
when I switch the expression parser over to use the
new Materializer.
llvm-svn: 179416
to the Materializer. Materialization is still done by
the ClangExpressionDeclMap; this will be the next thing
to move.
Also fixed a layout bug that this uncovered.
llvm-svn: 179318
information about each variable that needs to
be materialized for an expression to work. The
next step is to migrate all materialization code
from ClangExpressionDeclMap to Materializer, and
to use it for variable materialization.
llvm-svn: 179245
Paul Herman