by LLDB. Instead of being materialized into the input structure
passed to the expression, variables are left in place and pointers
to them are materialzied into the structure. Variables not resident
in memory (notably, registers) get temporary memory regions allocated
for them.
Persistent variables are the most complex part of this, because they
are made in various ways and there are different expectations about
their lifetime. Persistent variables now have flags indicating their
status and what the expectations for longevity are. They can be
marked as residing in target memory permanently -- this is the
default for result variables from expressions entered on the command
line and for explicitly declared persistent variables (but more on
that below). Other result variables have their memory freed.
Some major improvements resulting from this include being able to
properly take the address of variables, better and cleaner support
for functions that return references, and cleaner C++ support in
general. One problem that remains is the problem of explicitly
declared persistent variables; I have not yet implemented the code
that makes references to them into indirect references, so currently
materialization and dematerialization of these variables is broken.
llvm-svn: 123371
values or persistent expression variables. Now if an expression consists of
a value that is a child of a variable, or of a persistent variable only, we
will create a value object for it and make a ValueObjectConstResult from it to
freeze the value (for program variables only, not persistent variables) and
avoid running JITed code. For everything else we still parse up and JIT code
and run it in the inferior.
There was also a lot of clean up in the expression code. I made the
ClangExpressionVariables be stored in collections of shared pointers instead
of in collections of objects. This will help stop a lot of copy constructors on
these large objects and also cleans up the code considerably. The persistent
clang expression variables were moved over to the Target to ensure they persist
across process executions.
Added the ability for lldb_private::Target objects to evaluate expressions.
We want to evaluate expressions at the target level in case we aren't running
yet, or we have just completed running. We still want to be able to access the
persistent expression variables between runs, and also evaluate constant
expressions.
Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects
can now dump their contents with the UUID, arch and full paths being logged with
appropriate prefix values.
Thread hardened the Communication class a bit by making the connection auto_ptr
member into a shared pointer member and then making a local copy of the shared
pointer in each method that uses it to make sure another thread can't nuke the
connection object while it is being used by another thread.
Added a new file to the lldb/test/load_unload test that causes the test a.out file
to link to the libd.dylib file all the time. This will allow us to test using
the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else.
llvm-svn: 121745
Added a ThreadPlanCallUserExpression that differs from ThreadPlanCallFunction in that it holds onto a shared pointer to its ClangUserExpression so that can't go away before the thread plan is done using it.
Fixed the stop message when you hit a breakpoint while running a user expression so it is more obvious what has happened.
llvm-svn: 120386
adding support into lldb_private::Process:
virtual uint32_t
lldb_private::Process::LoadImage (const FileSpec &image_spec,
Error &error);
virtual Error
lldb_private::Process::UnloadImage (uint32_t image_token);
There is a default implementation that should work for both linux and MacOSX.
This ability has also been exported through the SBProcess API:
uint32_t
lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec,
lldb::SBError &error);
lldb::SBError
lldb::SBProcess::UnloadImage (uint32_t image_token);
Modified the DynamicLoader plug-in interface to require it to be able to
tell us if it is currently possible to load/unload a shared library:
virtual lldb_private::Error
DynamicLoader::CanLoadImage () = 0;
This way the dynamic loader plug-ins are allows to veto whether we can
currently load a shared library since the dynamic loader might know if it is
currenlty loading/unloading shared libraries. It might also know about the
current host system and know where to check to make sure runtime or malloc
locks are currently being held.
Modified the expression parser to have ClangUserExpression::Evaluate() be
the one that causes the dynamic checkers to be loaded instead of other code
that shouldn't have to worry about it.
llvm-svn: 118227
which holds the name of a file whose contents are
prefixed to each expression. For example, if the file
~/lldb.prefix.header contains:
typedef unsigned short my_type;
then you can do this:
(lldb) settings set target.expr-prefix '~/lldb.prefix.header'
(lldb) expr sizeof(my_type)
(unsigned long) $0 = 2
When the variable is changed, the corresponding file
is loaded and its contents are fetched into a string
that is stored along with the target. This string
is then passed to each expression and inserted into
it during parsing, like this:
typedef unsigned short my_type;
void
$__lldb_expr(void *$__lldb_arg)
{
sizeof(my_type);
}
llvm-svn: 117627
debug information and you evaluated an expression, a crash would occur as a
result of an unchecked pointer.
Added the ability to get the expression path for a ValueObject. For a rectangle
point child "x" the expression path would be something like: "rect.top_left.x".
This will allow GUI and command lines to get ahold of the expression path for
a value object without having to explicitly know about the hierarchy. This
means the ValueObject base class now has a "ValueObject *m_parent;" member.
All ValueObject subclasses now correctly track their lineage and are able
to provide value expression paths as well.
Added a new "--flat" option to the "frame variable" to allow for flat variable
output. An example of the current and new outputs:
(lldb) frame variable
argc = 1
argv = 0x00007fff5fbffe80
pt = {
x = 2
y = 3
}
rect = {
bottom_left = {
x = 1
y = 2
}
top_right = {
x = 3
y = 4
}
}
(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffe80
pt.x = 2
pt.y = 3
rect.bottom_left.x = 1
rect.bottom_left.y = 2
rect.top_right.x = 3
rect.top_right.y = 4
As you can see when there is a lot of hierarchy it can help flatten things out.
Also if you want to use a member in an expression, you can copy the text from
the "--flat" output and not have to piece it together manually. This can help
when you want to use parts of the STL in expressions:
(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffea8
hello_world._M_dataplus._M_p = 0x0000000000000000
(lldb) expr hello_world._M_dataplus._M_p[0] == '\0'
llvm-svn: 116532
bool ValueObject::GetIsConstant() const;
void ValueObject::SetIsConstant();
This will stop anything from being re-evaluated within the value object so
that constant result value objects can maintain their frozen values without
anything being updated or changed within the value object.
Made it so the ValueObjectConstResult can be constructed with an
lldb_private::Error object to allow for expression results to have errors.
Since ValueObject objects contain error objects, I changed the expression
evaluation in ClangUserExpression from
static Error
ClangUserExpression::Evaluate (ExecutionContext &exe_ctx,
const char *expr_cstr,
lldb::ValueObjectSP &result_valobj_sp);
to:
static lldb::ValueObjectSP
Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr);
Even though expression parsing is borked right now (pending fixes coming from
Sean Callanan), I filled in the implementation for:
SBValue SBFrame::EvaluateExpression (const char *expr);
Modified all expression code to deal with the above changes.
llvm-svn: 115589
results. The clang opaque type for the expression result will be added to the
Target's ASTContext, and the bytes will be stored in a DataBuffer inside
the new object. The class is named: ValueObjectConstResult
Now after an expression is evaluated, we can get a ValueObjectSP back that
contains a ValueObjectConstResult object.
Relocated the value object dumping code into a static function within
the ValueObject class instead of being in the CommandObjectFrame.cpp file
which is what contained the code to dump variables ("frame variables").
llvm-svn: 115578
arguments are specified in a standardized way, will have a standardized name, and
have functioning help.
The next step is to start writing useful help for all the argument types.
llvm-svn: 115335
accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.
While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.
Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").
llvm-svn: 114252
- If you put a semicolon at the end of an expression,
this no longer causes the expression parser to
error out. This was a two-part fix: first,
ClangExpressionDeclMap::Materialize now handles
an empty struct (such as when there is no return
value); second, ASTResultSynthesizer walks backward
from the end of the ASTs until it reaches something
that's not a NullStmt.
- ClangExpressionVariable now properly byte-swaps when
printing itself.
- ClangUtilityFunction now cleans up after itself when
it's done compiling itself.
- Utility functions can now use external functions just
like user expressions.
- If you end your expression with a statement that does
not return a value, the expression now runs correctly
anyway.
Also, added the beginnings of an Objective-C object
validator function, which is neither installed nor used
as yet.
llvm-svn: 113789
expressions. Values used by the expression are
checked by validation functions which cause the
program to crash if the values are unsafe.
Major changes:
- Added IRDynamicChecks.[ch], which contains the
core code related to this feature
- Modified CommandObjectExpression to install the
validator functions into the target process.
- Added an accessor to Process that gets/sets the
helper functions
llvm-svn: 112690
The goal is to separate the parser's data from the data
belonging to the parser's clients. This allows clients
to use the parser to obtain (for example) a JIT compiled
function or some DWARF code, and then discard the parser
state.
Previously, parser state was held in ClangExpression and
used liberally by ClangFunction, which inherited from
ClangExpression. The main effects of this refactoring
are:
- reducing ClangExpression to an abstract class that
declares methods that any client must expose to the
expression parser,
- moving the code specific to implementing the "expr"
command from ClangExpression and
CommandObjectExpression into ClangUserExpression,
a new class,
- moving the common parser interaction code from
ClangExpression into ClangExpressionParser, a new
class, and
- making ClangFunction rely only on
ClangExpressionParser and not depend on the
internal implementation of ClangExpression.
Side effects include:
- the compiler interaction code has been factored
out of ClangFunction and is now in an AST pass
(ASTStructExtractor),
- the header file for ClangFunction is now fully
documented,
- several bugs that only popped up when Clang was
deallocated (which never happened, since the
lifetime of the compiler was essentially infinite)
are now fixed, and
- the developer-only "call" command has been
disabled.
I have tested the expr command and the Objective-C
step-into code, which use ClangUserExpression and
ClangFunction, respectively, and verified that they
work. Please let me know if you encounter bugs or
poor documentation.
llvm-svn: 112249
expression parser. There shouldn't be four separate
classes encapsulating a variable.
ClangExpressionVariable is now meant to be the
container for all variable information. It has
several optional components that hold data for
different subsystems.
ClangPersistentVariable has been removed; we now
use ClangExpressionVariable instead.
llvm-svn: 111600
additional (ComandReturnObject *) result parameter (default to NULL) and does
the right thing in setting the result status.
Also removed used variable ast_context.
llvm-svn: 110992
expression. It is now possible to do things like this:
(lldb) expr int $i = 5; $i + 1
$0 = (int) 6
(lldb) expr $i + 3
$1 = (int) 8
(lldb) expr $1 + $0
$2 = (int) 14
As a bonus, this allowed us to move printing of
expression results into the ClangPersistentVariable
class. This code needs a bit of refactoring -- in
particular, ClangExpressionDeclMap has eaten one too
many bacteria and needs to undergo mitosis -- but the
infrastructure appears to be holding up nicely.
llvm-svn: 110896
expression parser. It is now possible to type:
(lldb) expr int $i = 5; $i + 1
(int) 6
(lldb) expr $i + 2
(int) 7
The skeleton for automatic result variables is
also implemented. The changes affect:
- the process, which now contains a
ClangPersistentVariables object that holds
persistent variables associated with it
- the expression parser, which now uses
the persistent variables during variable
lookup
- TaggedASTType, where I loaded some commonly
used tags into a header so that they are
interchangeable between different clients of
the class
llvm-svn: 110777
made IR-based expression evaluation the default.
Also added a new class to hold persistent variables.
The class is empty as yet while I write up a design
document for what it will do. Also the place where
it is currently created (by the Expression command)
is certainly wrong.
llvm-svn: 110415
- When we JIT an expression, we print the disassembly
of the generated code
- When we put the structure into the target, we print
the individual entries in the structure byte for
byte.
llvm-svn: 109278
to be executed by the inferior. This required explicit support
from RecordingMemoryManager for finding the address range
belonging to a particular function.
Also fixed a bug in DisassemblerLLVM where the disassembler
assumed there was an AddressRange available even when it was
NULL.
llvm-svn: 109209
and moved it to its own header file for cleanliness.
Added more logging to ClangFunction so that we can
diagnose crashes in the executing expression.
Added code to extract the result of the expression
from the struct that is passed to the JIT-compiled
code.
llvm-svn: 109199
defines that are in "llvm/Support/MachO.h". This should allow ObjectFileMachO
and ObjectContainerUniversalMachO to be able to be cross compiled in Linux.
Also did some cleanup on the ASTType by renaming it to ClangASTType and
renaming the header file. Moved a lot of "AST * + opaque clang type *"
functionality from lldb_private::Type over into ClangASTType.
llvm-svn: 109046
used by the JIT compiled expression, including the
result of the expression.
Also added a new class, ASTType, which encapsulates an
opaque Clang type and its associated AST context.
Refactored ClangExpressionDeclMap to use ASTTypes,
significantly reducing the possibility of mixups of
types from different AST contexts.
llvm-svn: 108965
to correctly unfold constant-folded global variables.
Also added code to JIT the expression. Simple
expressions are now JIT compiled successfully.
llvm-svn: 108380
prepare IR for execution in the target. Wired the
expression command to use this IR transformer when
conversion to DWARF fails, and wired conversion to
DWARF to always fail (well, we don't generate any
DWARF...)
llvm-svn: 107559
an expression, adding code to put the value of the
last expression (if there is one) into a variable
and write the address of that variable to a global
pointer.
llvm-svn: 107419
intelligently. The four name types we currently have are:
eFunctionNameTypeFull = (1 << 1), // The function name.
// For C this is the same as just the name of the function
// For C++ this is the demangled version of the mangled name.
// For ObjC this is the full function signature with the + or
// - and the square brackets and the class and selector
eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class
// methods or selectors will be searched.
eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments
eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names
this allows much more flexibility when setting breakoints:
(lldb) breakpoint set --name main --basename
(lldb) breakpoint set --name main --fullname
(lldb) breakpoint set --name main --method
(lldb) breakpoint set --name main --selector
The default:
(lldb) breakpoint set --name main
will inspect the name "main" and look for any parens, or if the name starts
with "-[" or "+[" and if any are found then a full name search will happen.
Else a basename search will be the default.
Fixed some command option structures so not all options are required when they
shouldn't be.
Cleaned up the breakpoint output summary.
Made the "image lookup --address <addr>" output much more verbose so it shows
all the important symbol context results. Added a GetDescription method to
many of the SymbolContext objects for the more verbose output.
llvm-svn: 107075
- Rationalized EvaluateExpression to remove a lot
of nesting; also added comments to make it easy
to find what's happening where
- Made ExecuteRawCommandString subcontract out to
EvaluateExpression
- Minor logging improvements
llvm-svn: 106703
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create());
// Use which ever file handles you wish
debugger.SetErrorFileHandle (stderr, false);
debugger.SetOutputFileHandle (stdout, false);
debugger.SetInputFileHandle (stdin, true);
// main loop
SBDebugger::Terminate(); // (static function)
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.
Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.
llvm-svn: 106615
Fixed the Disassemble arguments so you can't specify start address or name in multiple ways.
Fixed the command line input so you can specify the filename without "-f" even if you use other options.
llvm-svn: 106020
Sean Callanan