use the python API that is exposed through SWIG to do some cool stuff.

Also fixed synchronous debugging so that all process control APIs exposed
through the python API will now wait for the process to stop if you set
the async mode to false (see disasm.py).

llvm-svn: 115738

symbol.

llvm-svn: 115734

Restored the ability to set the format for expressions after changing the expression results over to ValueObjectSP objects.

llvm-svn: 115733

where the symbol index was set to INDIRECT_SYMBOL_ABS and was causing an
assertion to fire when we loaded older Mac OS X binaries.

llvm-svn: 115729

functions it finds in libraries unless it cannot find
an external function with the desired name.

llvm-svn: 115721

Add a comment for 'breakpoint set -M C' not working correctly for clang.

llvm-svn: 115712

arguments to the expression parser.  This means that
structs can be returned from the "expr" command.

llvm-svn: 115698

so that expressions can use them.

llvm-svn: 115658

Add a test class to call lldb 'disassemble -n function' command on each call frame when stopped on C's ctor.
This is not a long running test so it shall always be exercised.

llvm-svn: 115653

Add a utility function to lldbtest.py to get the native pointer size of the host os.

llvm-svn: 115652

llvm-svn: 115636

    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

ClangUserExpression::Evaluate () as a public static function so anyone can
evaluate an expression.

llvm-svn: 115581

llvm-svn: 115579

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

llvm-svn: 115574

llvm-svn: 115572

(for standardized argument names, argument help, etc.)

llvm-svn: 115570

patch by Arvid Picciani!

llvm-svn: 115563

Add a "Confirm" function to the CommandInterpreter so you can confirm potentially dangerous operations in a generic way.

llvm-svn: 115546

llvm-svn: 115543

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

llvm-svn: 115535

Fixed and issue where we weren't seeing inlined functions anymore. We also now show the correct pc-offset within the inlined function. 

llvm-svn: 115522

llvm-svn: 115519

the {function.name}, is sufficient for this test case.

Plus added @expectedfailure decorator for a filed bug.

llvm-svn: 115517

${module.file.basename}{`${function.name}, is sufficient for this test case.

llvm-svn: 115514

Remove file:lineno from the expected substrings.

llvm-svn: 115512

llvm-svn: 115491

was stopped in a module, yet had no valid function for the PC, no module would
be displayed.

llvm-svn: 115490

llvm-svn: 115488

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

have now all passed.

rdar://problem/8502549 and rdar://problem/8493023 are fixed

llvm-svn: 115399

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

regexp once and use it within the for loop for some speedup.

llvm-svn: 115397

with importing class/struct types.

llvm-svn: 115394

depending on the compiler used.  Former if gcc/llvm-gcc, and latter if clang.

llvm-svn: 115380

    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

right name pools.

llvm-svn: 115371

llvm-svn: 115369