to be included from lldb.swig: python-typemaps.swig and python-wrapper.swig.

llvm-svn: 136117

the pid of the process currently being debugged by debugserer in
hex, or 0 if unavailable.

This is effectively the same as the qC packet but that packet is
not clear in either its documentation or implementation (in gdb et al)
as to whether it is intended to return a pid or a thread id.  qGetPid
is unambiguous.

If qGetPid is unimplemented in the remote debugserver, the debugger may
try qC and see what kind of value is returned..

llvm-svn: 136055

Indent the frames in the "thread.GetStatus" frame listing.  Also put the same space after each thread listing for "thread backtrace all" as "thread backtrace 1 3 5"

llvm-svn: 136052

llvm-svn: 136028

llvm-svn: 136026

llvm-svn: 136016

    for child in value:
        # do something with the child value

and SBValue.linked_list_iter():

    for task in task_head.linked_list_iter('next', eol_test):
        # visit each item in the linked list

llvm-svn: 136015

llvm-svn: 135997

llvm-svn: 135989

the SBValue.linked_list_iter() API is equal to [1, 2, 4, 5].

llvm-svn: 135944

to iterate through an SBValue instance by treating it as the head of a linked
list.  API program must provide two args to the linked_list_iter() method:
the first being the child member name which points to the next item on the list
and the second being a Python function which an SBValue (for the next item) and
returns True if end of list is reached, otherwise it returns False.

For example, suppose we have the following sample program.

#include <stdio.h>

class Task {
public:
    int id;
    Task *next;
    Task(int i, Task *n):
        id(i),
        next(n)
    {}
};


int main (int argc, char const *argv[])
{
    Task *task_head = new Task(-1, NULL);
    Task *task1 = new Task(1, NULL);
    Task *task2 = new Task(2, NULL);
    Task *task3 = new Task(3, NULL); // Orphaned.
    Task *task4 = new Task(4, NULL);
    Task *task5 = new Task(5, NULL);

    task_head->next = task1;
    task1->next = task2;
    task2->next = task4;
    task4->next = task5;

    int total = 0; // Break at this line
    Task *t = task_head;
    while (t != NULL) {
        if (t->id >= 0)
            ++total;
        t = t->next;
    }
    printf("We have a total number of %d tasks\n", total);
    return 0;
}

The test program produces the following output while exercising the linked_list_iter() SBVAlue API:

task_head:
	TypeName      -> Task *
	ByteSize      -> 8
	NumChildren   -> 2
	Value         -> 0x0000000106400380
	ValueType     -> local_variable
	Summary       -> None
	IsPointerType -> True
	Location      -> 0x00007fff65f06e60
(Task *) next = 0x0000000106400390
  (int) id = 1
  (Task *) next = 0x00000001064003a0

(Task *) next = 0x00000001064003a0
  (int) id = 2
  (Task *) next = 0x00000001064003c0

(Task *) next = 0x00000001064003c0
  (int) id = 4
  (Task *) next = 0x00000001064003d0

(Task *) next = 0x00000001064003d0
  (int) id = 5
  (Task *) next = 0x0000000000000000

llvm-svn: 135938

Python synthetic providers must provide a num_children call; this was not specified in the docs up to now

llvm-svn: 135933

added a final newline to fooSynthProvider.py
new option to automatically save user input in InputReaderEZ
checking for NULL pointers in several new places

llvm-svn: 135916

 - you can now define a Python class as a synthetic children producer for a type
   the class must adhere to this "interface":
        def __init__(self, valobj, dict):
     	def get_child_at_index(self, index):
     	def get_child_index(self, name):
   then using type synth add -l className typeName
   (e.g. type synth add -l fooSynthProvider foo)
   (This is still WIP with lots to be added)
   A small test case is available also as reference

llvm-svn: 135865

Don't delete & remake the exception breakpoints every time you need them.  Make them once & enable/disable
them as appropriate.
Also reformatted the lldb summaries to make them easier to read, and added one.  I'll do more as I get time.

llvm-svn: 135827

value and the decendents.  For an example,

rdf = lldbutil.RecursiveDecentFormatter(indent_child=2)
print rdf.format(g_table)

produces:

(const char **[2]) g_table = 0x00000001055a80f0 (location)
  (const char **) [0] = 0x00000001055a8080
    (const char *) *[0] = "Sunday"
  (const char **) [1] = 0x00000001055a80c0
    (const char *) *[1] = "Monday"

llvm-svn: 135815

SetLoadAddress (lldb::addr_t load_addr, 
               	lldb::SBTarget &target);

llvm-svn: 135793

and fix RegisterContextDarwin_x86_64.cpp build

RegisterContextDarwin_arm.cpp contains too much platform specific code
to easily fix.

llvm-svn: 135792

llvm-svn: 135791

some code to use it

llvm-svn: 135790

debugging printfs() for data visualization turned into a meaningful log:
 - introduced a new log category `types' in channel `lldb'

llvm-svn: 135773

API. 

SBTarget changes include changing:

bool
SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr, 
                              lldb::SBAddress& addr);

to be:

lldb::SBAddress
SBTarget::ResolveLoadAddress (lldb::addr_t vm_addr);

SBAddress can how contruct itself using a load address and a target 
which can be used to resolve the address:

SBAddress (lldb::addr_t load_addr, lldb::SBTarget &target);

This will actually just call the new SetLoadAddress accessor:

void
SetLoadAddress (lldb::addr_t load_addr, 
                lldb::SBTarget &target);

This function will always succeed in making a SBAddress object
that can be used in API calls (even if "target" isn't valid).
If "target" is valid and there are sections currently loaded,
then it will resolve the address to a section offset address if
it can. Else an address with a NULL section and an offset that is
the "load_addr" that was passed in. We do this because a load address
might be from the heap or stack.

llvm-svn: 135770

llvm-svn: 135737

which provide some convenient ways to print an SBValue object.  Use that in TestValueAPI.py
to print the 'days_of_week' char* array variable.

For an example:

cvf = lldbutil.ChildVisitingFormatter(indent=2)
print cvf.format(days_of_week)

produces:

(const char *[7]) days_of_week = 0x00000001026a5060 (location)
  (const char *) [0] = "Sunday"
  (const char *) [1] = "Monday"
  (const char *) [2] = "Tuesday"
  (const char *) [3] = "Wednesday"
  (const char *) [4] = "Thursday"
  (const char *) [5] = "Friday"
  (const char *) [6] = "Saturday"

llvm-svn: 135736

when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object
 (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

llvm-svn: 135716

llvm-svn: 135699

invoking the Read(...) method to read in bytes.  Similar to r135461.

llvm-svn: 135695

If we are telling only one thread to run in debugserver, and that thread has been suspended from outside
the debugger, resume it before running so we will actually make progress.

llvm-svn: 135655

essentials contains two small summaries that you might really want to use; lldb contains some basic summaries for use in debugging LLDB itself. to use them, you must type category enable lldb

llvm-svn: 135653

llvm-svn: 135652

llvm-svn: 135648

llvm-svn: 135647

llvm-svn: 135642

llvm-svn: 135631

llvm-svn: 135630

llvm-svn: 135615

llvm-svn: 135606

of Apple gcc build which produces wrong namespace for std::string in debug info.

llvm-svn: 135597

Also we now display a live update of the kexts that we are loading.

llvm-svn: 135563