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
the stdc++ library module. Right now, it doesn't do any disassembly at all. It
merely locates the stdc++ library. Also tests the SBProcess object description
and verifies it is in a 'Stopped' state.
llvm-svn: 115536
instance:
settings set frame-format <string>
settings set thread-format <string>
This allows users to control the information that is seen when dumping
threads and frames. The default values are set such that they do what they
used to do prior to changing over the the user defined formats.
This allows users with terminals that can display color to make different
items different colors using the escape control codes. A few alias examples
that will colorize your thread and frame prompts are:
settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n'
settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n'
A quick web search for "colorize terminal output" should allow you to see what
you can do to make your output look like you want it.
The "settings set" commands above can of course be added to your ~/.lldbinit
file for permanent use.
Changed the pure virtual
void ExecutionContextScope::Calculate (ExecutionContext&);
To:
void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&);
I did this because this is a class that anything in the execution context
heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell
you what it was really trying to do unless you look at the parameter.
llvm-svn: 115485
operator naming stuff. We now get the constructor and destructor names right
after passing in the type, and we get the correct conversion operator name
after passing in the return type when getting the DeclarationNameInfo.
llvm-svn: 115398
ARG: (struct objc_selector *) _cmd
to
ARG: (SEL) _cmd
The change most likely resulted from an update from the llvm tot with a newer clang.
llvm-svn: 115372
To not skip long running tests, pass '-l' to the test driver (dotest.py).
An example:
@unittest2.skipIf(TestBase.skipLongRunningTest(), "Skip this long running test")
def test_foundation_disasm(self):
...
o Added a long running disassemble test to the foundation directory, which iterates
the code symbols from Foundation.framework and kicks off a disassemble command for
for the named function symbol. Found a crasher: rdar://problem/8504895.
o Plus added/updated some comments for the TestBase class.
llvm-svn: 115368
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
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
sets some breakpoints and invokes 'disassemble' when the breakpoint hits, which
just disassembles the bytes in the current function, i.e., frame #0's function.
llvm-svn: 115249
# rdar://problem/8493023
# test/types failures for Test*TypesExpr.py: element offset computed wrong and sign error?
Two failures remain for test_short* test cases.
llvm-svn: 115229
Added the start of Host specific launch services, though it currently isn't
hookup up to anything. We want to be able to launch a process and use the
native launch services to launch an app like it would be launched by the
user double clicking on the app. We also eventually want to be able to run
a command line app in a newly spawned terminal to avoid terminal sharing.
Fixed an issue with the new DWARF forward type declaration stuff. A crasher
was found that was happening when trying to properly expand the forward
declarations.
llvm-svn: 115213
Sean Callanan