aboutsummaryrefslogtreecommitdiff
path: root/lldb/scripts/Python
AgeCommit message (Collapse)AuthorFilesLines
2012-12-12Fixed a few bugs in the "step in" thread plan logic.Jim Ingham1-0/+3
Added a "step-in-target" flag to "thread step-in" so if you have something like: Process 28464 stopped * thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1 frame #0: 0x0000000100000e08 a.out`main at main.c:62 61 -> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint. 63 and you want to get into "complex" skipping a, b and c, you can do: (lldb) step -t complex Process 28464 stopped * thread #1: tid = 0x1c03, function: complex , stop reason = step in frame #0: 0x0000000100000d0d a.out`complex at main.c:44 41 42 int complex (int first, int second, int third) 43 { -> 44 return first + second + third; // Step in targetting complex should stop here 45 } 46 47 int main (int argc, char const *argv[]) llvm-svn: 170008
2012-12-10Make sure that the lldb globals:Greg Clayton1-2/+8
lldb.target lldb.process lldb.thread lldb.frame are initialized to at least contain empty lldb classes in case some python gets imported that uses them. llvm-svn: 169750
2012-12-08Added GetCanonicalType() to SBType:Greg Clayton1-0/+3
lldb::SBType SBType::GetCanonicalType(); llvm-svn: 169655
2012-12-05<rdar://problem/12749733>Greg Clayton2-0/+5
Always allows getting builtin types by name even if there is no backing debug information. llvm-svn: 169424
2012-12-05<rdar://problem/12649160>Greg Clayton1-0/+1
Added the ability to debug through your process exec'ing itself to the same architecture. llvm-svn: 169340
2012-12-04<rdar://problem/12750060>Greg Clayton2-3/+16
Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects. llvm-svn: 169205
2012-11-29Match extern "C" in declaration and definition (swig template)Daniel Malea1-0/+8
- Fix for building with gcc 4.6 llvm-svn: 168901
2012-11-17<rdar://problem/12720514> Sub-TLF: Provide service to profile the inferiorHan Ming Ong1-1/+5
This allows client to query profiling states on the inferior. llvm-svn: 168228
2012-11-01Makefile patches from Charles Davis and Daniel Malea (+ one or two tweaks).Filipe Cabecinhas3-22/+85
llvm-svn: 167242
2012-10-30Added the ability to get function return and argument types to SBType():Greg Clayton1-1/+13
bool SBType::IsFunctionType (); lldb::SBType SBType::GetFunctionReturnType (); lldb::SBTypeList SBType::GetFunctionArgumentTypes (); llvm-svn: 167023
2012-10-29Ensuring that the swig typemaps for SBData set the size to 0 along with the ↵Enrico Granata1-0/+5
pointer to NULL There should be no functional changes as SBData creation functions already checked for NULL regardless of size - but it ensures consistency llvm-svn: 166978
2012-10-26Add API to get the process plugin name & short name.Jim Ingham1-0/+6
llvm-svn: 166799
2012-10-23<rdar://problem/12523238> Commit 1 of 3Enrico Granata1-65/+97
This commit enables the new HasChildren() feature for synthetic children providers Namely, it hooks up the required bits and pieces so that individual synthetic children providers can implement a new (optional) has_children call Default implementations have been provided where necessary so that any existing providers continue to work and behave correctly Next steps are: 2) writing smart implementations of has_children for our providers whenever possible 3) make a test case llvm-svn: 166495
2012-10-23<rdar://problem/12493007>Greg Clayton1-0/+3
Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. llvm-svn: 166460
2012-10-22<rdar://problem/12437442>Enrico Granata2-0/+16
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
2012-10-16API cleanup.Greg Clayton1-42/+19
llvm-svn: 166070
2012-10-16Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham4-0/+112
"expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
2012-10-16Removing the two extra GetXSize(bool) calls since we do not desire to ↵Enrico Granata1-6/+0
support them long-term llvm-svn: 166060
2012-10-16<rdar://problem/12446320> Fixing an issue with our Driver where setting an ↵Enrico Granata1-3/+15
immediate output would not cause suppression of the final printout. This allows effective output redirection for Python commands llvm-svn: 166058
2012-10-13<rdar://problem/12490588>Greg Clayton1-0/+3
From SBType, we can now get a lldb::BasicType enumeration out of an existing type. llvm-svn: 165857
2012-10-12<rdar://problem/12490558>Greg Clayton1-1/+1
SBProcess::SetSelectedThreadByID() had a "uint32_t tid" parameter which would truncate 64 bit thread IDs (lldb::tid_t is 64 bit). llvm-svn: 165852
2012-10-10<rdar://problem/12462744> Implement a new SBDeclaration class to wrap an ↵Enrico Granata4-0/+80
lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration llvm-svn: 165672
2012-10-10Change the Thread constructor over to take a Process& rather than a ↵Jim Ingham1-0/+12
ProcessSP. We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP. Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame changes the stack. Made the Driver use this notification to print the new thread status rather than doing it in the command. Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call. <rdar://problem/12383087> llvm-svn: 165640
2012-10-08Fix a build warning and a dangerous possible crasher.Greg Clayton1-1/+1
llvm-svn: 165460
2012-10-08<rdar://problem/12200505> Fixing a logical error in SBProcess, where the ↵Enrico Granata1-2/+3
get_process_thread_list function was creating invalid threads_access instances, and hence failing to correctly fill in the list llvm-svn: 165421
2012-10-08Silly me! There was a closing ) missing from one of the lines - and Python ↵Enrico Granata1-1/+1
complained about syntax errors on the next line. It being a Friday afternoon made the rest llvm-svn: 165420
2012-10-08Retrying to apply Vishal's patch - hopefully this time it won't break ↵Enrico Granata1-12/+20
Jason's build llvm-svn: 165410
2012-10-06Revert Vishal's patch that Enrico commited, at least for the weekend. With ↵Jason Molenda1-20/+11
it applied, starting lldb I get % ./lldb -x Traceback (most recent call last): File "<string>", line 1, in <module> File "/private/tmp/build/Debug/LLDB.framework/Versions/A/Resources/Python/lldb/__init__.py", line 9008 raise TypeError("No array item of type %s" % str(type(key))) ^ SyntaxError: invalid syntax Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined (lldb) I did a clean build and still got the problem so I'm backing this out until Enrico can look at it. llvm-svn: 165356
2012-10-06patch from Vishal Patel to improve our lldb.value wrapperEnrico Granata1-11/+20
llvm-svn: 165348
2012-10-05<rdar://problem/12442990> Fix the implementation of lldb.value.__eq__Enrico Granata1-1/+9
llvm-svn: 165344
2012-10-05Add one-shot breakpoints (-o option to "break set") and a tbreak alias for ↵Jim Ingham1-0/+6
our gdb friends. llvm-svn: 165328
2012-10-04<rdar://problem/12099999> renaming SBStream::Printf to Print in the ↵Enrico Granata1-3/+9
scripting world in order to avoid supporting varargs through SWIG llvm-svn: 165274
2012-09-28Implementing plugins that provide commands.Enrico Granata3-1/+7
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface There is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin. Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" command For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands Caveats: Currently, the new API objects and features are not exposed via Python. The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object) There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins There is no API exposed for option parsing, which means you may need to use getopt or roll-your-own llvm-svn: 164865
2012-09-27Patch from Dan Malea to get the Bourne shells scripts to run cleanly on ↵Jason Molenda2-30/+30
Ubuntu. llvm-svn: 164801
2012-09-25Add an API to figure out whether a breakpoint is internal or not.Jim Ingham1-0/+3
llvm-svn: 164648
2012-09-14Fixed some problems with SWIG bindings.Filipe Cabecinhas2-11/+13
This may (but shouldn't) break Linux (but I tested and it still worked on FreeBSD). The same shell scripts are now used on Xcode and Makefiles, for generating the SWIG bindings. Some compatibility fixes were applied, too (python path, bash-isms, etc). llvm-svn: 163912
2012-09-14Make the unwinding of the stack part of "thread return" work, and add the ↵Jim Ingham1-1/+1
thread return command. llvm-svn: 163867
2012-09-12Start at getting "thread return" working. Doesn't work yet.Jim Ingham1-0/+3
llvm-svn: 163670
2012-08-28Simplify the typecheck code.Filipe Cabecinhas1-10/+4
llvm-svn: 162753
2012-08-27Fixing a potential control may reach end of non-void function issueEnrico Granata1-0/+1
llvm-svn: 162685
2012-08-25Added SBDebugger's log callbacks to Python-landFilipe Cabecinhas4-32/+91
- Tweaked a parameter name in SBDebugger.h so my typemap will catch it; - Added a SBDebugger.Create(bool, callback, baton) to the swig interface; - Added SBDebugger.SetLoggingCallback to the swig interface; - Added a callback utility function for log callbacks; - Guard against Py_None on both callback utility functions; - Added a FIXME to the SBDebugger API test; - Added a __del__() stub for SBDebugger. We need to be able to get both the log callback and baton from an SBDebugger if we want to protect against memory leaks (or make the user responsible for holding another reference to the callback). Additionally, it's impossible to revert from a callback-backed log mechanism to a file-backed log mechanism. llvm-svn: 162633
2012-08-24Fixing a bunch of issues with the OS plugin codeEnrico Granata1-1/+1
llvm-svn: 162527
2012-08-24Adding bindings to the Script Interpreter for some basic Python OS plugin ↵Enrico Granata1-0/+97
functionality (still WIP) llvm-svn: 162513
2012-08-22Fixed a Linux building bug pointed out by Daniel Malea.Filipe Cabecinhas1-1/+1
llvm-svn: 162373
2012-08-22Added a typemap and wrappers for SBInputReader callbacksFilipe Cabecinhas3-1/+87
Now it's possible to use SBInputReader callbacks in Python. We leak the callback object, unfortunately. A __del__ method can be added to SBInputReader, but we have no way to check the callback function that is on the reader. So we can't call Py_DECREF on it when we have our PythonCallback function. One way to do it is to assume that reified SBInputReaders always have a Python callback (and always call Py_DECREF). Another one is to add methods or properties to SBInputReader (or make the m_callback_function property public). llvm-svn: 162356
2012-08-20Fix a crash (_wrap_SBDebugger_SetInputFileHandle -> PyString_AsString) ↵Johnny Chen1-2/+9
running the test suite. Also modify the boundary condition test case SBDebugger.DispatchInput(None) to be wrapped inside a try-except clause for now. llvm-svn: 162228
2012-08-20A baton isn't needed to dispatch input.Filipe Cabecinhas2-1/+17
I also added a typemap to make DispatchInput usable in Python. llvm-svn: 162204
2012-08-20Add FILE* typemaps for SBDebugger.GetInputFileHandle() and friends.Filipe Cabecinhas1-0/+35
llvm-svn: 162203
2012-08-18Merge python-GIL bracnh (by filcab) back into trunk!Johnny Chen1-1/+1
llvm-svn: 162161
2012-08-09rdar://problem/11457143 [ER] need "watchpoint command ..."Johnny Chen1-0/+79
Add 'watchpoint command add/delete/list' to lldb, plus two .py test files. llvm-svn: 161638
generated by cgit v1.1 at 2025-10-07 04:33:03 +0000