summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBCommandInterpreter.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow specifying an exit code for the 'quit' commandRaphael Isemann2018-07-111-0/+17
| | | | | | | | | | | | | | | | | | | Summary: This patch adds the possibility to specify an exit code when calling quit. We accept any int, even though it depends on the user what happens if the int is out of the range of what the operating system supports as exit codes. Fixes rdar://problem/38452312 Reviewers: davide, jingham, clayborg Reviewed By: jingham Subscribers: clayborg, jingham, lldb-commits Differential Revision: https://reviews.llvm.org/D48659 llvm-svn: 336824
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Implement interactive command interruptionLeonard Mosescu2017-10-051-0/+4
| | | | | | | | | | | | | | | | | | | The core of this change is the new CommandInterpreter::m_command_state, which models the state transitions for interactive commands, including an "interrupted" state transition. In general, command interruption requires cooperation from the code executing the command, which needs to poll for interruption requests through CommandInterpreter::WasInterrupted(). CommandInterpreter::PrintCommandOutput() implements an optionally interruptible printing of the command output, which for large outputs was likely the longest blocking part. (ex. target modules dump symtab on a complex binary could take 10+ minutes) Differential Revision: https://reviews.llvm.org/D37923 llvm-svn: 315037
* Revert patch r313904, as it breaks "command source" and in Jim Ingham2017-09-281-4/+0
| | | | | | | | | | | | particular causes lldb to die on startup if you have a ~/.lldbinit file. I filed: https://bugs.llvm.org/show_bug.cgi?id=34758 to cover fixing the bug. llvm-svn: 314371
* [LLDB] Implement interactive command interruptionAdrian McCarthy2017-09-211-0/+4
| | | | | | | | | | | | | | | | | | | | | The core of this change is the new CommandInterpreter::m_command_state, which models the state transitions for interactive commands, including an "interrupted" state transition. In general, command interruption requires cooperation from the code executing the command, which needs to poll for interruption requests through CommandInterpreter::WasInterrupted(). CommandInterpreter::PrintCommandOutput() implements an optionally interruptible printing of the command output, which for large outputs was likely the longest blocking part. (ex. target modules dump symtab on a complex binary could take 10+ minutes) patch by lemo Differential Revision: https://reviews.llvm.org/D37923 llvm-svn: 313904
* Make CommandObject help getters/setters use StringRef.Zachary Turner2016-11-121-2/+4
| | | | llvm-svn: 286731
* Convert some more aliasing and CI functions to StringRef.Zachary Turner2016-10-051-1/+1
| | | | llvm-svn: 283386
* Convert CommandObject constructors to StringRef.Zachary Turner2016-10-051-1/+1
| | | | llvm-svn: 283384
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-560/+457
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Improve code of loading plugins that provide cmndsAbhishek Aggarwal2016-07-291-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Modified code that enables writing new user-defined commands and use them through LLDB CLI. Modifications are: -- Define the 'syntax' for each user-defined command --- Added an argument in SBCommandInterpreter::AddCommand() and SBCommand::AddCommand() API --- Allow passing syntax for each user-defined command --- Earlier, only 'help' could be defined and passed for commands -- Passed 'number of arguments' entered on CLI for user-defined commands --- Added an argument (number of options) in SBCommandPluginInterface::DoExecute() API to know the number of arguments passed for commands -- In CommandPluginInterfaceImplementation class: --- Make the data member m_backend a shared_ptr --- Avoids memory leaks of dynamically allocated SBCommandPluginInterface instances created in lldb::PluginInitialize() API Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: jingham, granata.enrico, clayborg Subscribers: labath, lldb-commits Differential Revision: https://reviews.llvm.org/D22863 llvm-svn: 277125
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-5/+5
| | | | llvm-svn: 270024
* Fix Clang-tidy modernize-use-nullptr warnings in include/lldb/API and ↵Eugene Zelenko2015-10-311-89/+61
| | | | | | | | source/API; other minor fixes. Other fixes should reduce number of readability-redundant-smartptr-get and readability-implicit-bool-cast. llvm-svn: 251733
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Add support for custom commands to set flags on themselvesEnrico Granata2015-05-271-0/+15
| | | | | | | | | This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags()) Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ... Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones llvm-svn: 238286
* Factor resolution of abbreviations and aliases so that they can be tested ↵Adrian McCarthy2015-04-231-0/+16
| | | | | | directly. http://reviews.llvm.org/D9033 llvm-svn: 235633
* Rework LLDB system initialization.Zachary Turner2015-03-311-177/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an effort to reduce binary size for components not wishing to link against all of LLDB, as well as a parallel effort to reduce link dependencies on Python, this patch splits out the notion of LLDB initialization into "full" and "common" initialization. All code related to initializing the full LLDB suite lives directly in API now. Previously it was only referenced from API, but because it was defined in lldbCore, it would get implicitly linked against by everything including lldb-server, causing a considerable increase in binary size. By moving this to the API layer, it also creates a better layering for the ongoing effort to make the embedded interpreter replacable with one from a different language (or even be completely removeable). One semantic change necessary to get this all working was to remove the notion of a shared debugger refcount. The debugger is either initialized or uninitialized now, and calling Initialize() multiple times will simply have no effect, while the first Terminate() will now shut it down no matter how many times Initialize() was called. This behaves nicely with all of our supported usage patterns though, and allows us to fix a number of nasty hacks from before. Differential Revision: http://reviews.llvm.org/D8462 llvm-svn: 233758
* Turn off 'quit' confirmation in lldb-miIlia K2015-03-231-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: # Turn off interpreter.prompt-on-quit on startup (MI) # Add CommandInterpreter::SetPromptOnQuit # Add SBCommandInterpreter::GetPromptOnQuit/SetPromptOnQuit All tests pass on OS X. Test Plan: ``` -file-exec-and-symbols ~/p/hello -break-insert -f main -exec-run -interpreter-exec console quit ``` Reviewers: abidh, clayborg Reviewed By: abidh, clayborg Subscribers: lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8444 llvm-svn: 233034
* Compare pointers directly instead of ::strcmp in SBXxx::EventIsXxxEvent()Ilia K2015-03-211-1/+1
| | | | llvm-svn: 232892
* Fix handling of CommandInterpreter's events in lldb-miIlia K2015-03-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously lldb-mi contains a stub for that but it didn't work and all CommanInterpreter's events were ignored. This commit adds a handling of CommandInterpreter's events in lldb-mi. Steps: # Fix CMICmnLLDBDebugger::InitSBListener # Add SBCommandInterpreter::EventIsCommandInterpreterEvent # Exit on lldb::SBCommandInterpreter::eBroadcastBitQuitCommandReceived All tests pass on OS X. In further we can remove "quit" hack in lldb-mi. Test Plan: # Create start_script file: ``` target create ~/p/hello b main r quit ``` # Run lldb-mi --interpreter # Execute start_script file by following command: ``` -interpreter-exec console "command source start_script" ``` Log: ``` $ bin/lldb-mi --interpreter (gdb) -interpreter-exec console "command source start_script" Executing commands in '/Users/IliaK/p/llvm/build_ninja/start_script'. (lldb) target create ~/p/hello Current executable set to '~/p/hello' (x86_64). (lldb) b main Breakpoint 1: where = hello`main + 29 at hello.cpp:12, address = 0x0000000100000e2d (lldb) r Process 1582 launched: '/Users/IliaK/p/hello' (x86_64) (lldb) quit ^done (gdb) =thread-created,id="1",group-id="i1" =thread-selected,id="1" (gdb) =shlibs-added,shlib-info=[num="1",name="hello",dyld-addr="-",reason="dyld",path="/Users/IliaK/p/hello",loaded_addr="-",dsym-objpath="/Users/IliaK/p/hello.dSYM/Contents/Resources/DWARF/hello"] ... =shlibs-added,shlib-info=[num="132",name="libDiagnosticMessagesClient.dylib",dyld-addr="0x7fff91705000",reason="dyld",path="/usr/lib/libDiagnosticMessagesClient.dylib",loaded_addr="0x7fff91705000"] (gdb) *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x100000e2d",func="main",args=[{name="argc",value="1"},{name="argv",value="0x00007fff5fbffc88"}],file="hello.cpp",fullname="/Users/IliaK/p/hello.cpp",line="12"},thread-id="1",stopped-threads="all" (gdb)<press Enter> MI: Program exited OK ``` Reviewers: abidh, clayborg Reviewed By: abidh Subscribers: jingham, lldb-commits, clayborg, abidh Differential Revision: http://reviews.llvm.org/D8382 llvm-svn: 232891
* Fix broadcasters for interpreter and process:Ilia K2015-03-171-2/+1
| | | | | | | | # Fix CommandInterpreter.Broadcaster name (it should be the same as CommandInterpreter::GetStaticBroadcasterClass()) # Prevent the same error in Process.Broadcaster # Fix SBCommandInterpreter::GetBroadcasterClass (it should call CommandInterpreter::GetStaticBroadcasterClass(), was Communication::GetStaticBroadcasterClass()) llvm-svn: 232500
* Handle PyLong return values in LLDBSwigPython_CalculateNumChildren.Siva Chandra2015-03-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Also, change its return type to size_t to match the return types of its callers. With this change, std::vector and std::list data formatter tests pass on Linux (when using libstdc++) with clang as well as with gcc. These tests have also been enabled in this patch. Test Plan: dotest.py -p <TestDataFormatterStdVector|TestDataFormatterStdList> Reviewers: vharron, clayborg Reviewed By: clayborg Subscribers: zturner, lldb-commits Differential Revision: http://reviews.llvm.org/D8337 llvm-svn: 232399
* Add accessors on SBCommand to get and set the help texts for a commandEnrico Granata2015-03-131-0/+22
| | | | llvm-svn: 232226
* Bulk of the infrastructure work to allow script commands to be backed by ↵Enrico Granata2015-03-131-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | object instances in addition to free functions This works by creating a command backed by a class whose interface should - at least - include def __init__(self, debugger, session_dict) def __call__(self, args, return_obj, exe_ctx) What works: - adding a command via command script add --class - calling a thusly created command What is missing: - support for custom help - test cases The missing parts will follow over the next couple of days This is an improvement over the existing system as: a) it provides an obvious location for commands to provide help strings (i.e. methods) b) it allows commands to store state in an obvious fashion c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-) llvm-svn: 232136
* Further reduce header footprint of Debugger.h.Zachary Turner2015-03-041-0/+1
| | | | llvm-svn: 231202
* Enable Python summaries to use custom SBTypeSummaryOptions if the user is so ↵Enrico Granata2014-11-221-0/+1
| | | | | | inclined. Updates to the webdoc will follow llvm-svn: 222593
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+7
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* This adds a "batch mode" to lldb kinda like the gdb batch mode. It will ↵Jim Ingham2014-10-141-1/+67
| | | | | | | | | | | | | | | | quit the debugger after all the commands have been executed except if one of the commands was an execution control command that stopped because of a signal or exception. Also adds a variant of SBCommandInterpreter::HandleCommand that takes an SBExecutionContext. That way you can run an lldb command targeted at a particular target, thread or process w/o having to select same before running the command. Also exposes CommandInterpreter::HandleCommandsFromFile to the SBCommandInterpreter API, since that seemed generally useful. llvm-svn: 219654
* Rework the way we pass "run multiple command" options to the various API's thatJim Ingham2014-10-111-0/+94
| | | | | | | | | | | | | | | do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather the options into an options class. Also expose that to the SB API's. Change the way the "-o" options to the lldb driver are processed so: 1) They are run synchronously - didn't really make any sense to run the asynchronously. 2) The stop on error 3) "quit" in one of the -o commands will not quit lldb - not the command interpreter that was running the -o commands. I added an entry to the run options to stop-on-crash, but I haven't implemented that yet. llvm-svn: 219553
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-0/+4
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Allow Python commands to optionally take an SBExecutionContext argument in ↵Enrico Granata2014-10-011-1/+2
| | | | | | case they need to handle 'where they want to act' separately from the notion of 'currently-selected entity' that is associated to the debugger. Do this in an (hopefully) non-breaking way by running an argcount check before passing in the new argument. Update the test case to also check for this new feature. www update to follow llvm-svn: 218834
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-1/+14
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Any commands that are executed through the public interface using ↵Greg Clayton2014-07-151-0/+1
| | | | | | | | | | | | | | SBCommandInterpreter::HandleCommand() are assumed to be in non-interactive mode. Any commands that want interactivity (stdin) will need to be executed through the normal command interpreter using the debugger's in/out/err file handles, or by using "command source". Individual commands through the API will have their STDIN disabled. The STDOUT and STDERR will be redirected into the SBCommandReturnObject argument to SBCommandInterpreter::HandleCommand() as usual. This helps with a deadlock situation in an IDE (Xcode) where the IDE was managing the breakpoint actions by setting a breakpoint callback and doing things manually. <rdar://problem/17386271> llvm-svn: 213023
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-22/+32
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+2
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-0/+16
| | | | | | | | | | | | 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
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-3/+3
| | | | | | | | | | 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-021-3/+3
| | | | | | | | | | | | | | | | | | | | | 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
* Fixed the MacOSX non "Debug" builds so that "lldb-platform" doesn't fail to ↵Greg Clayton2013-10-171-9/+116
| | | | | | link. llvm-svn: 192857
* <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
* <rdar://problem/12586010>Greg Clayton2013-01-081-4/+0
| | | | | | | | Python OS plug-ins now fetch thread registers lazily. Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach". llvm-svn: 171901
* Fix Linux build warnings due to redefinition of macros:Daniel Malea2012-12-051-0/+2
| | | | | | | | | - add new header lldb-python.h to be included before other system headers - short term fix (eventually python dependencies must be cleaned up) Patch by Matt Kopec! llvm-svn: 169341
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-1/+1
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Added a new "module" log channel which covers module creation, deletion, and ↵Greg Clayton2012-10-081-1/+1
| | | | | | | | | | common module list actions. Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line. This was used to track down the leaking module issue I fixed last week. llvm-svn: 165438
* Implementing plugins that provide commands.Enrico Granata2012-09-281-2/+124
| | | | | | | | | | | | | | | | | | | 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
* Change UnwindAssemblyInstEmulation::GetNonCallSiteUnwindPlanFromAssembly so ↵Jason Molenda2012-07-171-2/+2
| | | | | | | | | | | | | | | | it records the state of the unwind instructions once the prologue has finished. If it hits an early return epilogue in the middle of the function, re-instate the prologue after that epilogue has completed so that we can still unwind for cases where the flow of control goes past that early-return. <rdar://problem/11775059> Move the UnwindPlan operator== definition into the .cpp file, expand the definition a bit. Add some casts to a SBCommandInterpreter::HandleCompletion() log statement so it builds without warning on 64- and 32-bit systems. llvm-svn: 160337
* Add API logging to SBCommandInterpreter::HandleCompletion().Jim Ingham2012-06-261-0/+8
| | | | llvm-svn: 159180
* <rdar://problem/11328896> Fixing a bug where regex commands were saved in ↵Enrico Granata2012-05-311-1/+1
| | | | | | the history even if they came from a 'command sourced' file - this fix introduces a command sourcing depth and disables history for all levels of depth > 0, which means no commands go into history when being sourced from a file. we need an integer depth because command files might themselves source other command files, ... llvm-svn: 157727
* <rdar://problem/10605072>Greg Clayton2012-05-081-1/+3
| | | | | | Fixed the command callback override lookup function so we can now override the "process launch" command (or any other multi-word commands). llvm-svn: 156368
* Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes. Jim Ingham2012-05-041-3/+3
| | | | | | | | | | | | | No one was using it and Locker(pthread_mutex_t *) immediately asserts for pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make that work, we should maintain the Mutex abstraction and not pass around the platform implementation... Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass your mutex to a Locker (you can't in fact, since I made it private.) llvm-svn: 156221
OpenPOWER on IntegriCloud