summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter
Commit message (Collapse)AuthorAgeFilesLines
...
* Don't build LLDBWrapPython.cpp for mingw.Hafiz Abid Qadeer2014-03-211-1/+2
| | | | | | | | | | Previous check relied on -DLLDB_DISABLE_PYTHON which was not valid as it is defined in the top level LLDB Makefile which is included after the check. If this check is moved after the inclusion of top level Makefile then BUILT_SOURCES is not properly handled. So I am using the scheme present in the Host/Makefile. llvm-svn: 204459
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-7/+0
| | | | | | | | | | | | | This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
* create constants for multichar constantsSaleem Abdulrasool2014-03-181-2/+6
| | | | | | | | Multichar constants are not portable as the byte order is undefined. Use a constant value instead. This avoids a warning when compiling with gcc 4.8+ (-Wmultichar) and makes the code more portable. llvm-svn: 204110
* Allow line numbers to be shown in multi-line expressions.Greg Clayton2014-03-071-0/+4
| | | | llvm-svn: 203185
* "size_t" isn't always 64 bit, it is 32 bit on 32 bit systems. All printf ↵Greg Clayton2014-03-031-1/+1
| | | | | | | | style statements that were assuming size_t were 64 bit were changed, and they were also changed to display them as unsigned values as "size_t" isn't signed. If you print anything with 'size_t', please cast it to "uint64_t" in the printf and use PRIu64 or PRIx64. llvm-svn: 202738
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-032-8/+8
| | | | llvm-svn: 202723
* Suppress python readline module under Linux to fix a seg fault.Todd Fiala2014-02-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bug fix for pr18841: http://llvm.org/bugs/show_bug.cgi?id=18841 This change creates a stub Python readline.so module that does almost nothing. Its whole purpose is to prevent Python from loading the real module, something it does during the embedded Python interpreter's initialization sequence (and way before lldb ever requests it within embedded_interpreter.py). On Ubuntu 12.04 and 13.10 x86_64, and in the Python 2.7.6 tree, the stock Python readline module links against the GNU readline library. This appears to be the case on all Pythons except where __APPLE__ is defined. LLDB now requires linking against the libedit library. Something about having both libedit.so and libreadline.so linked into the same process space is causing the Python readline.so to trigger a NULL memory access. I have put in a separate patch to python.org. This suppression of embedded interpreter readline support can be removed if at least any one of the following happens: 1. The stock python distribution accepts a patch similar to what I submitted to Python 2.7.6's Modules/readline.c file. 2. The stock python distribution implements Modules/readline.c in terms of libedit's readline compatibility mode (i.e. essentially compiles it the way __APPLE__ compiles that module) under Linux. 3. a clean-room implementation of the python readline module is implemented against libedit (either readline compatibility mode or native libedit). This could be implemented within the readline.cpp file that this change introduces. It cannot be a fork of python's readline.c module due to llvm licensing. The net effect of this change on Linux is that the embedded python's readline support will not exist. llvm-svn: 202243
* Fixed the command line LLDB so that "CTRL+C" will interrupt a running ↵Greg Clayton2014-02-241-1/+7
| | | | | | process again. llvm-svn: 202086
* Don't crash when we build with python enabled, yet we don't link in the ↵Greg Clayton2014-02-211-2/+2
| | | | | | | | lldb::SB* API layer. Previously the lldb-platform and lldb-gdbserver would crash. llvm-svn: 201872
* <rdar://problem/15906684>Enrico Granata2014-02-192-5/+7
| | | | | | | | The way in which we were determining whether a python module had already been imported in the current session stopped working due to the IOHandler changes As a result, importing in a new debug session a module which had been imported in a previous session did not work This commit restores that functionality by checking for the module's presence in the session dictionary (which should be more correct anyway) llvm-svn: 201623
* Fixed deadlocks that could occur when using python for breakpoints, ↵Greg Clayton2014-02-131-38/+48
| | | | | | | | | operating system plugins, and other async python usage. <rdar://problem/16054348> <rdar://problem/16040833> llvm-svn: 201372
* Now that the command interpreter runs in a separate thread in Xcode, we need ↵Greg Clayton2014-02-071-7/+1
| | | | | | | | | | | | | to lock the target API lock instead of trying to lock it. What was happening was: 1 - Xcode ran and stopped and was doing work on thread 2 2 - Users would type something in Xcode console on thread 1 3 - thread 3 would be running command interpreter thread and try to execute command but get "failed to get API lock" error for any command that wanted the target API lock (like "expression") <rdar://problem/15775016> llvm-svn: 200997
* Don't print out "script" results twice.Greg Clayton2014-02-051-9/+25
| | | | | | | | We now properly detect when a result object has an immediate output stream and don't echo the results a second time. <rdar://problem/15954906> llvm-svn: 200882
* Fixed output to display correctly for "command source" by fixing the correct ↵Greg Clayton2014-02-051-8/+14
| | | | | | | | | | flags being set. Also emit the "Executing commands" message so it properly only comes out when desired and so it comes out in the right place. <rdar://problem/15992208> llvm-svn: 200875
* Fixed an issue where "command source" would not do the right thing:Greg Clayton2014-02-051-37/+138
| | | | | | | - empty lines in init files would repeat previous command and cause errors to be displayed - all options to control showing the command, its output, if it should stop on error or continue, weren't being obeyed. llvm-svn: 200860
* <rdar://problem/15936507>Enrico Granata2014-02-051-7/+5
| | | | | | | | ScriptInterpreterPython caches the lldb.embedded_interpreter module, and since it caches it in a refcounting-safe PythonObject, the refcount will appropriately go down 1 every time a ScriptInterpreterPython is deallocated However, we were only importing the module once - in InitializePrivate(). In a handful of interpreter creations, the refcount on the run_one_line function would end up at 0, causing LLDB to crash This fixes it by also importing the module for every interpreter, which ensures correct refcounting llvm-svn: 200816
* Fixed b18655: cleaned up script interpreter file reference handling.Todd Fiala2014-01-301-5/+22
| | | | | | | | | | | | | | This change addresses shutdown crashes in the python lldb module when the script interpreter was hanging on to saved file references after leaving a session. It also gets rid of extra references to the stdin/stdout/stderr python file objects that are created when entering the session. This change also moves the bundled pyexpect 2.4 library to the front of the python library path so that a python distribution default pyexpect (2.3 in Ubuntu 12.04) is not picked up first. llvm-svn: 200486
* "script help (lldb.SBThread)" output stops before all output is displayed. ↵Greg Clayton2014-01-301-7/+9
| | | | | | | | Fixed now. <rdar://problem/15942977> llvm-svn: 200476
* Don't crash when trying to auto complete 'breakpoint set -n "_'Greg Clayton2014-01-291-1/+1
| | | | | | <rdar://problem/15921898> llvm-svn: 200402
* Merging the iohandler branch back into main. Greg Clayton2014-01-275-1265/+808
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Add a new-lineEnrico Granata2013-12-211-1/+1
| | | | llvm-svn: 197860
* Fix autocompletion for multi-word commands.Greg Clayton2013-12-101-7/+14
| | | | | | <rdar://problem/14183288> llvm-svn: 196949
* Fixed Makefile-based install to place python packages in the LLDB install tree.Sylvestre Ledru2013-12-061-1/+1
| | | | | | | | | Failure to install python packages now fails the make install. This patch properly handles the optional DESTDIR variable. Patch by Todd Fiala llvm-svn: 196624
* Revert: "Patch from Todd Fiala that install the lldb.py module in the prefix ↵Sylvestre Ledru2013-12-051-1/+1
| | | | | | | | directory and also makes install fail if the prefix directory can't be accessed" Does not respect the prefix llvm-svn: 196499
* Patch from Todd Fiala that install the lldb.py module in the prefix ↵Greg Clayton2013-12-041-1/+1
| | | | | | directory and also makes install fail if the prefix directory can't be accessed llvm-svn: 196413
* Fixed internal code to not link against and code from "lldb/API/*". Greg Clayton2013-12-022-3/+2
| | | | | | | | | | lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used. Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number. Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings. llvm-svn: 196141
* Also silent -Wno-cast-qual in the SWIG Python wrapper. Remove a huge number ↵Sylvestre Ledru2013-11-281-1/+1
| | | | | | of warnings llvm-svn: 195930
* Change lldb from building against a Python framework out ofJason Molenda2013-11-233-12/+0
| | | | | | | | | the installed SDK to using the current OS installed headers/libraries. This change is to address the removal of the Python framework from the Mac OS X 10.9 (Mavericks) SDK, and is the recommended workaround via https://developer.apple.com/library/mac/technotes/tn2328/_index.html llvm-svn: 195557
* Fixed a build warning for a missing switch case.Greg Clayton2013-11-081-0/+3
| | | | llvm-svn: 194295
* This patch does a couple of things. Jim Ingham2013-11-072-7/+7
| | | | | | | | | | | | | | | | | | | | | | It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-042-5/+5
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-022-5/+5
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
* Fix the format warnings.Sylvestre Ledru2013-10-311-4/+4
| | | | | | | | | | In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64. Fixes bug #17551. Patch by "/dev/humancontroller" llvm-svn: 193832
* <rdar://problem/14972424>Greg Clayton2013-10-171-18/+42
| | | | | | | | | | | | | | | - Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication - Finished up the target definition python setting stuff. - Added a new "slice" key/value pair that can specify that a register is part of another register: { 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' }, - Added a new "composite" key/value pair that can specify that a register is made up of two or more registers: { 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] }, - Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers: { 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']}, This now completes the feature that allows a GDB remote target to completely describe itself. llvm-svn: 192858
* Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to ↵Greg Clayton2013-10-172-121/+81
| | | | | | link. llvm-svn: 192857
* <rdar://problem/14972424>Greg Clayton2013-10-151-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the registers on the remote server. When those packets aren't supported, LLDB doesn't know what the registers look like. This checkin implements a setting that can be used to specify a python file that contains the registers definitions. The setting is: (lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py Inside module there should be a function: def get_dynamic_setting(target, setting_name): This dynamic setting function is handed the "target" which is a SBTarget, and the "setting_name", which is the name of the dynamic setting to retrieve. For the GDB remote target definition the setting name is 'gdb-server-target-definition'. The return value is a dictionary that follows the same format as the OperatingSystem plugins follow. I have checked in an example file that implements the x86_64 GDB register set for people to see: examples/python/x86_64_target_definition.py This allows LLDB to debug to any archticture that is support and allows users to define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo) are not supported by the remote GDB server. A few benefits of doing this in Python: 1 - The dynamic register context was already supported in the OperatingSystem plug-in 2 - Register contexts can use all of the LLDB enumerations and definitions for things like lldb::Format, lldb::Encoding, generic register numbers, invalid registers numbers, etc. 3 - The code that generates the register context can use the program to calculate the register context contents (like offsets, register numbers, and more) 4 - True dynamic detection could be used where variables and types could be read from the target program itself in order to determine which registers are available since the target is passed into the python function. This is designed to be used instead of XML since it is more dynamic and code flow and functions can be used to make the dictionary. llvm-svn: 192646
* Add the capability for LLDB to query an arbitrary Python module (passed in ↵Enrico Granata2013-10-141-1/+68
| | | | | | | | | | | as a file path) for target-specific settings This is implemented by means of a get_dynamic_setting(target, setting_name) function vended by the Python module, which can respond to arbitrary string names with dynamically constructed settings objects (most likely, some of those that PythonDataObjects supports) for LLDB to parse This needs to be hooked up to the debugger via some setting to allow users to specify which module will vend the information they want to supply llvm-svn: 192628
* <rdar://problem/15192088>Enrico Granata2013-10-111-1/+3
| | | | | | | gdb-format a (as in p/a) would fail as it needed to set a byte size (unsurprisingly enough) This should be acknowledged by the condition check and not cause a failure llvm-svn: 192511
* <rdar://problem/14393032>Enrico Granata2013-09-302-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
* Fix the command name in the syntax text for _regexp-listBen Langmuir2013-09-261-1/+1
| | | | llvm-svn: 191454
* Convert to UNIX line endings.Joerg Sonnenberger2013-09-251-46/+46
| | | | llvm-svn: 191367
* Change OptionValueFileSpec::SetValueFromCString to strip off whitespace,Jason Molenda2013-09-131-1/+14
| | | | | | | | single-quote and double-quotemarks from around file paths specified to settings like target.expr-prefix or target.process.python-os-plugin-path. <rdar://problem/14970457> llvm-svn: 190654
* Added a 'jump' command, similar to GDBs.Richard Mitton2013-09-121-0/+27
| | | | | | | | | This allows the PC to be directly changed to a different line. It's similar to the example python script in examples/python/jump.py, except implemented as a builtin. Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function) llvm-svn: 190572
* Restore -- "end of args" marker for shellEd Maste2013-09-051-1/+1
| | | | | | | I accidentally dropped this in r189879 in the change from /bin/bash to /bin/sh. llvm-svn: 190103
* OptionValueProperties::DeepCopy (): return empty value to avoid compilation ↵Virgile Bello2013-09-051-0/+1
| | | | | | error on MSVC (even if assert). llvm-svn: 190069
* Add OptionParser.hVirgile Bello2013-09-0516-134/+112
| | | | llvm-svn: 190063
* Switch '/bin/bash' to '/bin/sh'Ed Maste2013-09-031-1/+1
| | | | | | | | /bin/sh is more portable, and all systems with /bin/bash are expected to have /bin/sh as well, even if only a link to bash. Review: http://llvm-reviews.chandlerc.com/D1576 llvm-svn: 189879
* OptionValueFileSpec::SetValueFromCString() is passed a complete file ↵Jason Molenda2013-08-271-11/+2
| | | | | | | | | | | | | | pathname -- it should not split up that pathname itself or require quoting to avoid the same. This fixing a bug where target create -c "core file" or target create -s "symbol file" will fail with an error message that the paths haven't been properly quoted. Working around it required target create -c "core\ file" to survive both attemps at tokenizing. <rdar://problem/14230629> llvm-svn: 189313
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-263-6/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* MingW compilation (windows). Includes various refactoring to improve ↵Virgile Bello2013-08-232-0/+5
| | | | | | portability. llvm-svn: 189107
OpenPOWER on IntegriCloud