summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter/ScriptInterpreterPython.cpp
Commit message (Collapse)AuthorAgeFilesLines
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-261-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
* Add format specifiers to various format ids so we can print thread ids in ↵Michael Sartain2013-07-301-2/+2
| | | | | | | | | | decimal on Linux and FreeBSD. CC: emaste Differential Revision: http://llvm-reviews.chandlerc.com/D1234 llvm-svn: 187425
* Second attempt at getting the PyCallable changes in trunkEnrico Granata2013-07-091-10/+8
| | | | | | Thanks to Daniel Malea for helping test this patch for Linux happiness! llvm-svn: 185965
* Revert commits that cause broken builds on GCC buildbotsDaniel Malea2013-07-031-2/+4
| | | | | | | | - build fails due to PyCallable template definition inside an extern "C" scope This commit reverts 185240, 184893 and 184608. llvm-svn: 185560
* <rdar://problem/14266411>Enrico Granata2013-06-251-4/+2
| | | | | | | | | | | | The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened This checkin changes that: - SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string - script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior llvm-svn: 184893
* In thread and frame format strings, it is now allowed to use Python ↵Enrico Granata2013-06-201-0/+160
| | | | | | | | | | | | | | | functions to generate part or all of the output text Specifically, the ${target ${process ${thread and ${frame specifiers have been extended to allow a subkeyword .script:<fctName> (e.g. ${frame.script:FooFunction}) The functions are prototyped as def FooFunction(Object,unused) where object is of the respective SB-type (SBTarget for target.script, ... and so on) This has not been implemented for ${var because it would be akin to a Python summary which is already well-defined in LLDB llvm-svn: 184500
* Improvements to "command script import" to better support reloading in XcodeEnrico Granata2013-06-191-8/+26
| | | | | | | | | | | Xcode spawns a new LLDB SBDebugger for each debug session, and this was causing the reloading of python modules to fail across debug sessions (long story short: the module would not be loaded in the current instance of the ScriptInterpreter, but would still be present in sys.modules, hence the import call would just make a copy of it and not run it again Greg's new decorator uncovered the issue since it relies on actually loading the module's code rather than using __lldb_init_module as the active entity) This patch introduces the notion of a local vs. global import and crafts an appropriate command to allow reloading to work across debug sessions llvm-svn: 184279
* <rdar://problem/13926101>Enrico Granata2013-06-181-3/+17
| | | | | | | | Allow “command script import” to work with folder names that have a ‘ (tick) in them Kudos to StackOverflow (question 1494399) for the replace_all code! llvm-svn: 184158
* Making our Python decrefs NULL-safeEnrico Granata2013-06-111-7/+7
| | | | llvm-svn: 183774
* <rdar://problem/11109316>Enrico Granata2013-05-311-1/+4
| | | | | | | | | | | | | | | | | command script import now does reloads - for real If you invoke command script import foo and it detects that foo has already been imported, it will - invoke reload(foo) to reload the module in Python - re-invoke foo.__lldb_init_module This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing Usual caveats with Python imports persist. Among these: - if you have objects lurking around, reloading the module won't magically update them to reflect changes - if module A imports module B, reloading A won't reload B These are Python-specific issues independent of LLDB that would require more extensive design work The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not llvm-svn: 182977
* <rdar://problem/11158023>Enrico Granata2013-05-161-2/+8
| | | | | | Make type summary add and breakpoint command add show an helpful prototype + argument reference when manually typing Python code for these elements llvm-svn: 181968
* Test case added for importing packagesEnrico Granata2013-05-081-8/+10
| | | | llvm-svn: 181472
* Improvements to the package importing feature - test case will followEnrico Granata2013-05-081-4/+14
| | | | llvm-svn: 181461
* Fixed 'command script import' by eliminating the shadowing of basename.Ashok Thirumurthi2013-05-031-2/+1
| | | | | | Reviewed by: Daniel Malea llvm-svn: 181027
* <rdar://problem/11558812>Enrico Granata2013-05-021-27/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Allow command script import to load packages. e.g.: egranata$ ./lldb (lldb) command script import lldb.macosx.crashlog "crashlog" and "save_crashlog" command installed, use the "--help" option for detailed help "malloc_info", "ptr_refs", "cstr_refs", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help. The "unwind-diagnose" command has been installed, type "help unwind-diagnose" for detailed help. (lldb) ./lldb (lldb) command script import theFoo I am happy (lldb) fbc àèìòù (lldb) egranata$ ls theFoo/ __init__.py theBar.py egranata$ cat theFoo/__init__.py import lldb import theBar def __lldb_init_module(debugger, internal_dict): print "I am happy" debugger.HandleCommand("command script add -f theFoo.theBar.theCommand fbc") return None egranata$ cat theFoo/theBar.py #encoding=utf-8 def theCommand(debugger, command, result, internal_dict): result.PutCString(u"àèìòù") return None llvm-svn: 180975
* Avoiding a potentially memory allocating code path in the Python ↵Enrico Granata2013-04-291-17/+36
| | | | | | InputReader's CTRL+C handling code path - this can potentially cause a deadlock while interrupting a user-made Python command llvm-svn: 180726
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-6/+6
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-6/+6
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* <rdar://problem/13521159>Greg Clayton2013-03-271-8/+8
| | | | | | | | LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
* Implementing the notion of externally-acquirable ScriptInterpreter lockEnrico Granata2013-03-271-0/+10
| | | | | | | | | | | | | | With this notion, if parties outside the ScriptInterpreter itself need to acquire a lock on script APIs, they can do so by a pattern like this: { auto lock = interpeter->AcquireInterpreterLock(); // do whatever you need to do... } // lock will automatically be released here This might be useful for classes that use the Python convenience objects (e.g. PythonDictionary) to ensure they keep the underlying interpreter in a safe and controlled condition while they call through the C API functions Of course, the ScriptInterpreter still manages its internal locking correctly when necessary :-) llvm-svn: 178189
* This checkin removes the last Cocoa formatters that were implemented in ↵Enrico Granata2013-03-191-1/+1
| | | | | | Python and reimplements them in C++. The Python Cocoa formatters are not shipped as part of LLDB anymore, but still exist in the source repository for user reference. Python formatters still exist for STL classes and users can still define their own Python formatters llvm-svn: 177366
* <rdar://problem/13069948>Greg Clayton2013-01-251-1/+1
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* <rdar://problem/13010007>Greg Clayton2013-01-181-89/+182
| | | | | | | | | | | | | | | | | | | | | | | | | | Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method: class OperatingSystemPlugin: def create_thread(self, tid, context): # Return a dictionary for a new thread to create it on demand This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used. Cleaned up the code in PythonDataObjects.cpp/h: - renamed all classes that started with PythonData* to be Python*. - renamed PythonArray to PythonList. Cleaned up the code to use inheritance where - Centralized the code that does ref counting in the PythonObject class to a single function. - Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object. - Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form: - PyObject * - const PythonObject & - const lldb::ScriptInterpreterObjectSP & Cleaned up code in ScriptInterpreterPython: - Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time. - Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized. llvm-svn: 172873
* Remove std::string input arguments and replace with "const char *".Greg Clayton2013-01-161-64/+56
| | | | llvm-svn: 172647
* Make sure that the GenerateFunction call can support arbitrary levels of ↵Enrico Granata2013-01-071-2/+4
| | | | | | indentation for user code llvm-svn: 171810
* <rdar://problem/12446222>Enrico Granata2012-12-191-2/+26
| | | | | | | | | | | Implement the ability for Python commands to be interrupted by pressing CTRL+C Also add a new Mutex subclass that attempts to be helpful for debugging by logging actions performed on it FYI of all interested - there is a separate deadlocking issue related to how LLDB dispatches CTRL+C that might cause LLDB to deadlock upon pressing CTRL+C while in a Python command. This is not a regression, and was just previously masked by us not even trying to bail out of Python commands, so that it would not be clear from a user perspective whether we were deadlocked or stuck in an inconsistent state within the Python interpreter. llvm-svn: 170612
* Even when we aren’t going to init all the lldb.frame, etc, globals, init ↵Jim Ingham2012-12-081-0/+7
| | | | | | lldb.debugger, since each script interpreter is tied to just one debugger. llvm-svn: 169663
* More Linux warnings fixes (remove default labels as needed):Daniel Malea2012-12-071-2/+0
| | | | | | | | - as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations Patch by Matt Kopec! llvm-svn: 169633
* Separate initing the stdout/stderr for running the Python Script interpreter ↵Jim Ingham2012-12-071-30/+36
| | | | | | | | | | from initing the lldb.target/frame/etc globals, and only do the latter when it makes sense to. <rdar://problem/12554049> llvm-svn: 169614
* Fixed a crash in which we examined the extension ofSean Callanan2012-12-031-4/+7
| | | | | | | | | a file name, whether the file name had an extension or not. <rdar://problem/12793152> llvm-svn: 169156
* <rdar://problem/12676084> Dump the traceback when a Python error occurs in ↵Enrico Granata2012-11-301-15/+68
| | | | | | "command script import" and the exception is not an ImportError llvm-svn: 169031
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-5/+5
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Giving at least some error information when a Python exception happens ↵Enrico Granata2012-11-131-1/+11
| | | | | | during command script import llvm-svn: 167810
* Adding support for loading the scripting resource as part of a framework, ↵Enrico Granata2012-11-081-1/+1
| | | | | | | | lacking the dSYM bundle, or if the bundle has no Pythonic resources whatsoever Solving an issue where "command script import" would fail to pick the file indicated by the user as a result of something with the same name being in an earlier position in sys.path llvm-svn: 167570
* Get rid of hack by making the actual call public. This was causing the ↵Greg Clayton2012-11-011-1/+1
| | | | | | lldb-platform to not be able to link. llvm-svn: 167253
* <rdar://problem/12586188> Make ImportError a special case for "command ↵Enrico Granata2012-10-311-28/+62
| | | | | | | | | | | script import", such that the error message for the exception becomes the error for the entire import operation and silence the backtrace printout In the process, refactor the Execute* commands in ScriptInterpreter to take an options object, and add a new setting to not mask out errors so that the callers can handle them directly instead of having the default behavior llvm-svn: 167067
* <rdar://problem/11449953> Change Debugger::SetOutputFileHandle() so that it ↵Enrico Granata2012-10-291-0/+5
| | | | | | | | | does not automatically initialize the script interpreter in order to transfer its output file handle to it This should delay initialization of Python until strictly necessary and speed-up debugger startup Also, convert formatters for SEL and BOOL ObjC data-types from Python to C++, in order to reap more performance benefits from the above changes llvm-svn: 166967
* <rdar://problem/12523238> Commit 1 of 3Enrico Granata2012-10-231-5/+32
| | | | | | | | | | | | 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
* <rdar://problem/12479701> Use the plain pydoc pager to work around Python ↵Enrico Granata2012-10-221-3/+2
| | | | | | help() pagination conflicts with our I/O management llvm-svn: 166432
* <rdar://problem/12437442>Enrico Granata2012-10-221-30/+7
| | | | | | | | | | | 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
* <rdar://problem/12491420>Greg Clayton2012-10-181-13/+20
| | | | | | | | | | Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting: settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py Then run your program and see the extra threads. llvm-svn: 166244
* Fixing a logic error where we would incorrectly show the newly crafted ↵Enrico Granata2012-09-201-2/+3
| | | | | | function not found error for a Python function in some cases where the function actually existed and had an empty docstring llvm-svn: 164334
* <rdar://problem/12188843> Fixing a problem where a Python command created in ↵Enrico Granata2012-09-181-4/+13
| | | | | | the same module where the target function is defined causes the help string not to come out llvm-svn: 164172
* Made it so changes to the prompt via "settings set prompt" get noticed by ↵Greg Clayton2012-09-011-5/+5
| | | | | | | | | | the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
* The OS plug-in can now get data from a python script that implements the ↵Greg Clayton2012-08-241-2/+2
| | | | | | protocol. llvm-svn: 162540
* Fixing a bunch of issues with the OS plugin codeEnrico Granata2012-08-241-1/+7
| | | | llvm-svn: 162527
* Hooking up two more calls for the PythonOSPlugin stuff. The part of code to ↵Enrico Granata2012-08-241-0/+116
| | | | | | fetch the data and convert it to C++ objects is still missing, but will come llvm-svn: 162522
* Adding bindings to the Script Interpreter for some basic Python OS plugin ↵Enrico Granata2012-08-241-0/+88
| | | | | | functionality (still WIP) llvm-svn: 162513
* Merge python-GIL bracnh (by filcab) back into trunk!Johnny Chen2012-08-181-134/+75
| | | | llvm-svn: 162161
* Fix a race condition where multiple PythonInputReaderManager instances ↵Johnny Chen2012-08-171-30/+41
| | | | | | | | | | | | could, during destruction, tread on the m_embedded_thread_input_reader_sp singleton maintained by the script interpreter. Furthermore, use two additional slots under the script interpreter to store the PseudoTerminal and the InputReaderSP pertaining to the embedded python interpreter -- resulted from the ScriptInterpreterPython::ExecuteInterpreterLoop() call -- to facilitate separation from what is being used by the PythonInputReaderManager instances. llvm-svn: 162147
OpenPOWER on IntegriCloud