summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* 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
* Fixed several problems with watchpoint expressions.Sean Callanan2013-07-251-1/+1
| | | | | | | | | | | | | | | | - First, the watchpoint size was being cast to the wrong type. This is primarily cosmetic, but annoying. - Second, the options for the watchpoint command were not being initialized correctly, which led to the watchpoint size sometimes having absurdly large values. This caused watchpoints to fail to be set in some cases. <rdar://problem/12658775> llvm-svn: 187169
* Added Repr() and Str() member functions to our PythonObject class to allow ↵Enrico Granata2013-07-121-0/+22
| | | | | | easy conversion to-string of every PythonObject llvm-svn: 186205
* Second attempt at getting the PyCallable changes in trunkEnrico Granata2013-07-092-12/+20
| | | | | | 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-032-14/+6
| | | | | | | | - 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-252-6/+14
| | | | | | | | | | | | 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
* Fix some more mismatched integer types causing compiler warnings.Andy Gibbs2013-06-241-1/+1
| | | | llvm-svn: 184737
* 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
* Sort out a number of mismatched integer types in order to cut down the ↵Andy Gibbs2013-06-194-16/+16
| | | | | | number of compiler warnings. llvm-svn: 184333
* 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
* We were getting an assert because somebody was making a watchpoint that wasJim Ingham2013-06-181-2/+7
| | | | | | | | neither read nor write. Tighten up the checking so this isn't possible. <rdar://problem/14111167> llvm-svn: 184245
* Fix a missing pointer deref that was uncovered by one of the buildbots.Adrian Prantl2013-06-181-1/+1
| | | | llvm-svn: 184216
* This patch fixes the issue where our command-line tab completer would ↵Enrico Granata2013-06-181-13/+18
| | | | | | | | | | | | | | | | | sometimes replicate commands e.g. (lldb) pl<TAB> Available completions: platform plugin platform plugin Thanks to Matthew Sorrels for doing work and testing on this issue llvm-svn: 184212
* <rdar://problem/13270271>Enrico Granata2013-06-181-8/+1
| | | | | | | Only add the — (double dash) separator to a command syntax if it has any options to be separated from arguments Also remove the unused Translate() method from CommandObject llvm-svn: 184163
* <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
* Add new files to CMakeLists.txt to fix cmake build error.Michael Sartain2013-06-171-0/+1
| | | | llvm-svn: 184143
* <rdar://problem/14134716>Enrico Granata2013-06-172-65/+149
| | | | | | | | | | | | This is a rewrite of the command history facility of LLDB It takes the history management out of the CommandInterpreter into its own CommandHistory class It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5) It adds a new --wipe (-w) option to command history to allow clearing the history on demand It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be It adds a test case for the reimplemented facility llvm-svn: 184140
* <rdar://problem/11914077>Enrico Granata2013-06-121-0/+77
| | | | | | | If you type help command <word> <word> <word> <missingSubCommand> (e.g. help script import or help type summary fake), you will get help on the deepest matched command word (i.e. script or type summary in the examples) Also, reworked the logic for commands to produce their help to make it more object-oriented llvm-svn: 183822
* <rdar://problem/13299214>Enrico Granata2013-06-121-2/+4
| | | | | | Make the error message here more interesting for the user llvm-svn: 183818
* Making our Python decrefs NULL-safeEnrico Granata2013-06-111-7/+7
| | | | llvm-svn: 183774
* <rdar://problem/12876503>Enrico Granata2013-06-111-1/+10
| | | | | | | Adding a new setting interpreter.stop-command-source-on-error that dictates a default behavior for whether command source should stop upon hitting an error You can still override the setting for each individual invocation with the usual -e setting llvm-svn: 183719
* Fix various build warnings.Matt Kopec2013-06-031-2/+3
| | | | llvm-svn: 183140
* <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
* Fixed a file leak introduced with my last checkin. Also be sure to include ↵Greg Clayton2013-05-221-5/+8
| | | | | | <stdio.h> just in case. llvm-svn: 182537
OpenPOWER on IntegriCloud