from the frame is not valid, try look for the symbol in the symbol table.

llvm-svn: 131273

representing variables whose type must be inferred
from the way they are used.  Functions without debug
information now return UnknownAnyTy and must be cast.

Variables with no debug information are not yet using
UnknownAnyTy; instead they are assumed to be void*.
Support for variables of unknown type is coming (and,
in fact, some relevant support functions are included
in this commit) but will take a bit of extra effort.

The testsuite has also been updated to reflect the new
requirement that the result of printf be cast, i.e.

expr (int) printf("Hello world!")

llvm-svn: 131263

llvm-svn: 131253

    o get_parent_frame(frame)
    o get_args_as_string(frame)

to lldbutil.py and create TestFrameUtils.py to exercise the utils.
Plus re-arrange the test/python_api/lldbutil to have three directories
for testing iteration, process stack traces, and the just added frame utils.

llvm-svn: 131213

llvm-svn: 131168

llvm-svn: 131165

compile unit, which has an external reference to symbols defined in foo.m, the type query:

    in this case, 'expression (NSArray*)array_token'

continues to work.

This test is to accompany http://llvm.org/viewvc/llvm-project?rev=131145&view=rev.

llvm-svn: 131154

Add a utility function get_registers(frame, kind) to get the registers of a given frame and of a given kind.
Also add three convenience functions get_GPRs(frame), get_FPRs(frame), and get_ESRs(frame) to get the general
purpose registers, the floating point registers, and the exception state registers.

Add TestRegistersIterator.py to test these added functions of lldbutil.py.

llvm-svn: 131144

llvm-svn: 131111

for http://llvm.org/viewvc/llvm-project?rev=131089&view=rev.

llvm-svn: 131100

llvm-svn: 131072

of a universal binary and 'rax' register is available when launching the x86_64 slice.

rdar://problem/9403437

llvm-svn: 131069

llvm-svn: 131038

llvm-svn: 131035

llvm-svn: 131033

llvm-svn: 131011

llvm-svn: 130965

llvm-svn: 130963

llvm-svn: 130960

    for thread in process:
        print >> output, print_stacktrace(thread, string_buffer=True)

llvm-svn: 130940

o lldb.debugger
o lldb.target
o lldb.process
o lldb.thread
o lldb.frame

"just works" when we stop at a breakpoint.

llvm-svn: 130904

llvm-svn: 130865

llvm-svn: 130848

Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target,
and dynamic with running target.

llvm-svn: 130832

in one command invocation.

llvm-svn: 130811

llvm-svn: 130806

llvm-svn: 130804

llvm-svn: 130802

Use a more gentle way of shutting down the child process spawned during the test execution using pexpect.
Change some child.expect() to child.expect_exact() as they try to match the string, not a regular expression.

llvm-svn: 130797

Modify test_image_search_paths(self) to check for the pattern "%s-[^-]*-[^-]*" % self.getArchitecture()
from the output of running 'image list -t 3' command which lists the triples of the image list.

llvm-svn: 130777

llvm-svn: 130773

llvm-svn: 130771

Change one test sequence to detect the '** End Stop Hooks **' marker emitted by the
stop hooks mechanism and check for whether the 'expr ptr' stop-hook has been run.

Also, change the TestBase.tearDown() to wait for 2 seocnds before forcefully kill
the pexpect-spawned child lldb process.

llvm-svn: 130767

to spawn an lldb child command.  The test is not "correct" in that the '** Stop Hooks **'
message emitted by the Target implementation is invoked asynchronously and is using a separate:

    CommandReturnObject result;

command return object that what the driver passes to the normal command interpreter loop.
But it can help test our output serialization work.

I need to modify the test case later to maybe only test that "-o 'expr ptr'" option does indeed work.

llvm-svn: 130742

Add implementation of '==' and '!=' for SBFileSpec and SBModule.  Modify a test case to take advantage of 'ths_module == that_module'.

llvm-svn: 130709

llvm-svn: 130701

the breakpoint ID and provides the semantics needed for '==' and '!='.  And
modify LLDBIteratorTestCase.lldb_iter_2() to use '==' between two SBBreakpoint's.

llvm-svn: 130531

the lldb iteration protocol has been added to lldb.py module.

llvm-svn: 130452

This is so that the objects which support the iteration protocol are immediately obvious
from looking at the lldb.py file.

SBTarget supports two types of iterations: module and breakpoint.  For an SBTarget instance,
you will need to issue either:

    for m in target.module_iter()

or

    for b in target.breakpoint_iter()

For other single iteration protocol objects, just use, for example:

    for thread in process:
        ID = thread.GetThreadID()
        for frame in thread:
            frame.Disassemble()
            ....

llvm-svn: 130442

method names of all the lldb container objects and returns an iterator object when
passed an eligible lldb container object.

Example:

    from lldb_util import smart_iter
    for thread in smart_iter(process):
        ID = thread.GetThreadID()
        if thread.GetStopReason() == lldb.eStopReasonBreakpoint:
            stopped_due_to_breakpoint = True
        for frame in smart_iter(thread):
            self.assertTrue(frame.GetThread().GetThreadID() == ID)
        ...

Add a test case for lldb.smart_iter().

llvm-svn: 130332