to execute expressions even in the absence of a process.
This allows expressions to run in situations where the
target cannot run -- e.g., to perform calculations based
on type information, or to inspect a binary's static
data.
This modification touches the following files:
lldb-private-enumerations.h
Introduce a new enum specifying the policy for
processing an expression. Some expressions should
always be JITted, for example if they are functions
that will be used over and over again. Some
expressions should always be interpreted, for
example if the target is unsafe to run. For most,
it is acceptable to JIT them, but interpretation
is preferable when possible.
Target.[h,cpp]
Have EvaluateExpression now accept the new enum.
ClangExpressionDeclMap.[cpp,h]
Add support for the IR interpreter and also make
the ClangExpressionDeclMap more robust in the
absence of a process.
ClangFunction.[cpp,h]
Add support for the new enum.
IRInterpreter.[cpp,h]
New implementation.
ClangUserExpression.[cpp,h]
Add support for the new enum, and for running
expressions in the absence of a process.
ClangExpression.h
Remove references to the old DWARF-based method
of evaluating expressions, because it has been
superseded for now.
ClangUtilityFunction.[cpp,h]
Add support for the new enum.
ClangExpressionParser.[cpp,h]
Add support for the new enum, remove references
to DWARF, and add support for checking whether
the expression could be evaluated statically.
IRForTarget.[h,cpp]
Add support for the new enum, and add utility
functions to support the interpreter.
IRToDWARF.cpp
Removed
CommandObjectExpression.cpp
Remove references to the obsolete -i option.
Process.cpp
Modify calls to ClangUserExpression::Evaluate
to pass the correct enum (for dlopen/dlclose)
SBValue.cpp
Add support for the new enum.
SBFrame.cpp
Add support for he new enum.
BreakpointOptions.cpp
Add support for the new enum.
llvm-svn: 139772
Fixed up many API calls to not be "const" as const doesn't mean anything to
most of our lldb::SB objects since they contain a shared pointer, auto_ptr, or
pointer to the types which circumvent the constness anyway.
llvm-svn: 139428
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
Also change the SourceInitFile to look for .lldb-<APPNAME> and source that
preferentially if it exists.
Also made the breakpoint site report its address as well as its breakpoint number
when it gets hit and can't find any the associated locations (usually because the
breakpoint got disabled or deleted programmatically between the time it was hit
and reported.)
Changed ThreadPlanCallFunction to initialize the ivar m_func in the initializers of the
constructor, rather than waiting to initialize till later on in the function.
Fixed a bug where if you make an SBError and the ask it Success, it returns false.
Fixed ValueObject::ResolveValue so that it resolves a temporary value, rather than
overwriting the one in the value object.
llvm-svn: 137536
*New setting target.max-children-count gives an upper-bound to the number of child objects that will be displayed at each depth-level
This might be a breaking change in some scenarios. To override the new limit you can use the --show-all-children (-A) option
to frame variable or increase the limit in your lldbinit file
*Command "type synthetic" has been split in two:
- "type synthetic" now only handles Python synthetic children providers
- the new command "type filter" handles filters
Because filters and synthetic providers are both ways to replace the children of a ValueObject, only one can be effective at any given time.
llvm-svn: 137416
The synthetic children providers now use the new (safer) APIs to get the values of objects
As a side effect, fixed an issue in ValueObject where ResolveValue() was not always updating the value before reading it
llvm-svn: 136861
the SBType implementation classes.
Fixed LLDB core and the test suite to not use deprecated SBValue APIs.
Added a few new APIs to SBValue:
int64_t
SBValue::GetValueAsSigned(int64_t fail_value=0);
uint64_t
SBValue::GetValueAsUnsigned(uint64_t fail_value=0)
llvm-svn: 136829
- Completely new implementation of SBType
- Various enhancements in several other classes
Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>:
- these return the actual elements into the container as the children of the container
- basic template name parsing that works (hopefully) on both Clang and GCC
- find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth
New summary string token ${svar :
- the syntax is just the same as in ${var but this new token lets you read the values
coming from the synthetic children provider instead of the actual children
- Python providers above provide a synthetic child len that returns the number of elements
into the container
Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB
Several other fixes, including:
- inverted the order of arguments in the ClangASTType constructor
- EvaluationPoint now only returns SharedPointer's to Target and Process
- the help text for several type subcommands now correctly indicates argument-less options as such
llvm-svn: 136504
(e.g. ${var%S}). this might already be the default if your variable is of an aggregate type
new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset
- the restricted list of children obeys the typical rules (e.g. summaries prevail over children)
- one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible
- to provide a synthetic children list use the "type synth add" command, as in:
type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4]
(you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported)
- a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones
llvm-svn: 135731
- help type summary add now gives some hints on how to use it
frame variable and target variable now have a --no-summary-depth (-Y) option:
- simply using -Y without an argument will skip one level of summaries, i.e.
your aggregate types will expand their children and display no summary, even
if they have one. children will behave normally
- using -Y<int>, as in -Y4, -Y7, ..., will skip as many levels of summaries as
given by the <int> parameter (obviously, -Y and -Y1 are the same thing). children
beneath the given depth level will behave normally
-Y0 is the same as omitting the --no-summary-depth parameter entirely
This option replaces the defined-but-unimplemented --no-summary
llvm-svn: 135336
represent pointers and arrays by adding an extra parameter to the
SBValue
SBValue::GetChildAtIndex (uint32_t idx,
DynamicValueType use_dynamic,
bool can_create_synthetic);
The new "can_create_synthetic" will allow you to create child values that
aren't actually a part of the original type. So if you code like:
int *foo_ptr = ...
And you have a SBValue that contains the value for "foo_ptr":
SBValue foo_value = ...
You can now get the "foo_ptr[12]" item by doing this:
v = foo_value.GetChiltAtIndex (12, lldb.eNoDynamicValues, True);
Normall the "foo_value" would only have one child value (an integer), but
we can create "synthetic" child values by treating the pointer as an array.
Likewise if you have code like:
int array[2];
array_value = ....
v = array_value.GetChiltAtIndex (0); // Success, v will be valid
v = array_value.GetChiltAtIndex (1); // Success, v will be valid
v = array_value.GetChiltAtIndex (2); // Fail, v won't be valid, "2" is not a valid zero based index in "array"
But if you use the ability to create synthetic children:
v = array_value.GetChiltAtIndex (0, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (1, lldb.eNoDynamicValues, True); // Success, v will be valid
v = array_value.GetChiltAtIndex (2, lldb.eNoDynamicValues, True); // Success, v will be valid
llvm-svn: 135292
- you can use a Python script to write a summary string for data-types, in one of
three ways:
-P option and typing the script a line at a time
-s option and passing a one-line Python script
-F option and passing the name of a Python function
these options all work for the "type summary add" command
your Python code (if provided through -P or -s) is wrapped in a function
that accepts two parameters: valobj (a ValueObject) and dict (an LLDB
internal dictionary object). if you use -F and give a function name,
you're expected to define the function on your own and with the right
prototype. your function, however defined, must return a Python string
- test case for the Python summary feature
- a few quirks:
Python summaries cannot have names, and cannot use regex as type names
both issues will be fixed ASAP
major redesign of type summary code:
- type summary working with strings and type summary working with Python code
are two classes, with a common base class SummaryFormat
- SummaryFormat classes now are able to actively format objects rather than
just aggregating data
- cleaner code to print descriptions for summaries
the public API now exports a method to easily navigate a ValueObject hierarchy
New InputReaderEZ and PriorityPointerPair classes
Several minor fixes and improvements
llvm-svn: 135238
would return instead of a less than helpful "name: '%s'" description.
Make sure that when we ask for the error from a ValueObject object we
first update the value if needed.
Cleaned up some SB functions to use internal functions and not re-call
through the public API when possible.
llvm-svn: 134497
Fixed crashes for SBValue fuzz calls.
And change 'bool SBType::IsPointerType(void)' to
'bool SBType::IsAPointerType(void)' to avoid name collision with the static 'bool SBType::IsPointerType(void *)'
function, which SWIG cannot handle.
llvm-svn: 134096
changes that caused all SBValue objects to completely ignore the target
lock due to bad C++ scoping of the target Mutex::Locker variables.
llvm-svn: 134081
pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will
stay around as long as that shared pointer stays around.
llvm-svn: 130035
expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.
The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.
There's also a general setting:
target.prefer-dynamic-value (boolean) = 'true'
which is consulted if you call "frame var" without supplying a value for the -d option.
llvm-svn: 129623
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.
A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed
yet:
class ExternalASTSource {
....
virtual void
CompleteType (clang::TagDecl *Tag);
virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);
};
This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.
This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
types.
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).
We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.
llvm-svn: 123613
Fixed the display of complex numbers in lldb_private::DataExtractor::Dump(...)
and also fixed other edge display cases in lldb_private::ClangASTType::DumpTypeValue(...).
llvm-svn: 122895
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.
llvm-svn: 118319
by type ID (the most common type of type lookup).
Changed the API logging a bit to always show the objects in the OBJECT(POINTER)
format so it will be easy to locate all instances of an object or references
to it when looking at logs.
llvm-svn: 117641
all of the calls inlined in the header file for better performance.
Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.
Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.
llvm-svn: 117437
- Try to reduce logging to one line per function call instead of tw
- Put all arguments & their values into log for calls
- Add 'this' parameter information to function call logging, making it show the appropriate
internal pointer (this.obj, this.sp, this.ap...)
- Clean up some return values
- Remove logging of constructors that construct empty objects
- Change '==>' to '=>' for showing result values...
- Fix various minor bugs
- Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments...
llvm-svn: 117417
it logs the function calls, their arguments and the return values. This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done. It currently does not
attempt to log all the functions, just the most important ones. I will be
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).
Update the Python build scripts to re-build the swig C++ file whenever
the python-extensions.swig file is modified.
Correct the help for 'log enable' command (give it the correct number & type of
arguments).
llvm-svn: 117349
Move anything that creates a new process into SBTarget. Marked some functions
as deprecated. I will remove them after our new API changes make it through
a build cycle.
llvm-svn: 115854
adding methods to C++ and objective C classes. In order to make methods, we
need the function prototype which means we need the arguments. Parsing these
could cause a circular reference that caused an assertion.
Added a new typedef for the clang opaque types which are just void pointers:
lldb::clang_type_t. This appears in lldb-types.h.
This was fixed by enabling struct, union, class, and enum types to only get
a forward declaration when we make the clang opaque qual type for these
types. When they need to actually be resolved, lldb_private::Type will call
a new function in the SymbolFile protocol to resolve a clang type when it is
not fully defined (clang::TagDecl::getDefinition() returns NULL). This allows
us to be a lot more lazy when parsing clang types and keeps down the amount
of data that gets parsed into the ASTContext for each module.
Getting the clang type from a "lldb_private::Type" object now takes a boolean
that indicates if a forward declaration is ok:
clang_type_t lldb_private::Type::GetClangType (bool forward_decl_is_ok);
So function prototypes that define parameters that are "const T&" can now just
parse the forward declaration for type 'T' and we avoid circular references in
the type system.
llvm-svn: 115012
into python-extensions.swig, which gets included into lldb.swig, and
adds them back into the classes when swig generates it's C++ file. This
keeps the Python stuff out of the general API classes.
Also fixed a small bug in the copy constructor for SBSymbolContext.
llvm-svn: 114602
SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger,
but could be extended. Also store the results of the ObjC Object Printer in a
Stream, not a ConstString.
llvm-svn: 113660
function statics, file globals and static variables) that a frame contains.
The StackFrame objects can give out ValueObjects instances for
each variable which allows us to track when a variable changes and doesn't
depend on variable names when getting value objects.
StackFrame::GetVariableList now takes a boolean to indicate if we want to
get the frame compile unit globals and static variables.
The value objects in the stack frames can now correctly track when they have
been modified. There are a few more tweaks needed to complete this work. The
biggest issue is when stepping creates partial stacks (just frame zero usually)
and causes previous stack frames not to match up with the current stack frames
because the previous frames only has frame zero. We don't really want to
require that all previous frames be complete since stepping often must check
stack frames to complete their jobs. I will fix this issue tomorrow.
llvm-svn: 112800
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
Sean Callanan