summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/Debugger.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* One of the changes Jim made in r286288 (cleaning up the stop printJason Molenda2017-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | header line, backtrace output) was to remove the current pc value from frames where we have source level information. We've been discussing this for the past week and based on input from a group of low level users, I believe this is the wrong default behavior for the command line lldb tool. lldb's backtrace will include the pc value for all stack frames regardless of whether they have source level debug information or not. A related part of r286288 removes the byte offset printing for functions with source level information (e.g. "main + 22 sourcefile.c:10" is printed as "main sourcefile.c:10"). I don't see a compelling case for changing this part of 286288 so I'm leaving that as-is (in addition to the rest of 286288 which is clearly better than the previous output style). <rdar://problem/30083904> llvm-svn: 293366
* Use Timeout<> in the Listener classPavel Labath2016-11-301-2/+2
| | | | | | | | | | | | | | | | | | | | Summary: Communication classes use the Timeout<> class to specify the timeout. Listener class was converted to chrono some time ago, but it used a different meaning for a timeout of zero (Listener: infinite wait, Communication: no wait). Instead, Listener provided separate functions which performed a non-blocking event read. This converts the Listener class to the new Timeout class, to improve consistency. It also allows us to get merge the different GetNextEvent*** and WaitForEvent*** functions into one. No functional change intended. Reviewers: jingham, clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D27136 llvm-svn: 288238
* Rewrite all Property related functions in terms of StringRef.Zachary Turner2016-11-171-8/+5
| | | | | | | | | | | | | | | This was a bit tricky, especially for things like OptionValueArray and OptionValueDictionary since they do some funky string parsing. Rather than try to re-write line-by-line I tried to make the StringRef usage idiomatic, even though it meant often re-writing from scratch large blocks of code in a different way while keeping true to the original intent. The finished code is a big improvement though, and often much shorter than the original code. All tests and unit tests pass on Windows and Linux. llvm-svn: 287242
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-1/+1
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Clean up the stop printing header lines.Jim Ingham2016-11-081-3/+25
| | | | | | | | | | | | | | | | I added a "thread-stop-format" to distinguish between the form that is just the thread info (since the stop printing immediately prints the frame info) and one with more frame 0 info - which is useful for "thread list" and the like. I also added a frame.no-debug boolean to the format entities so you can print frame information differently between frames with source info and those without. This closes https://reviews.llvm.org/D26383. <rdar://problem/28273697> llvm-svn: 286288
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-3/+3
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* Update the prompt related functions to use StringRefs.Zachary Turner2016-09-231-4/+4
| | | | llvm-svn: 282269
* add stop column highlighting supportTodd Fiala2016-09-211-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1498/+1265
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-3/+48
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-191-48/+3
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-3/+48
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* Clean up vestigial remnants of locking primitivesSaleem Abdulrasool2016-07-281-2/+2
| | | | | | | | | | | | | | | | This finally removes the use of the Mutex and Condition classes. This is an intricate patch as the Mutex and Condition classes were tied together. Furthermore, many places had slightly differing uses of time values. Convert timeout values to relative everywhere to permit the use of std::chrono::duration, which is required for the use of std::condition_variable's timeout. Adjust all Condition and related Mutex classes over to std::{,recursive_}mutex and std::condition_variable. This change primarily comes at the cost of breaking the TracingMutex which was based around the Mutex class. It would be possible to write a wrapper to provide similar functionality, but that is beyond the scope of this change. llvm-svn: 277011
* Fixed a threading race condition where we could crash after calling ↵Greg Clayton2016-07-111-2/+0
| | | | | | | | | | | | | | | | Debugger::Terminate(). The issue was we have two global variables: one that contains a DebuggerList pointer and one that contains a std::mutex pointer. These get initialized in Debugger::Initialize(), and everywhere that uses these does: if (g_debugger_list_ptr && g_debugger_list_mutex_ptr) { std::lock_guard<std::recursive_mutex> guard(*g_debugger_list_mutex_ptr); // do work while mutex is locked } Debugger::Terminate() was deleting and nulling out g_debugger_list_ptr which meant we had a race condition where someone might do the if statement and it evaluates to true, then another thread calls Debugger::Terminate() and deletes and nulls out g_debugger_list_ptr while holding the mutex, and another thread then locks the mutex and tries to use g_debugger_list_ptr. The fix is to just not delete and null out the g_debugger_list_ptr variable. llvm-svn: 275119
* Guard against the C++ destructor chain by not letting the debugger list ↵Greg Clayton2016-05-261-67/+49
| | | | | | | | | | clean up after itself in the C++ destructor chain. If users call "static void lldb::SBDebugger::Terminate()" we will clean up the debugger list, and users can individually destroy debugger instances with "static void lldb::SBDebugger::Destroy(SBDebugger &)". But if we let the C++ destructor chain tear down this list, other threads that might still be running as the main thread exits can now crash if they access the debugger list. We stop this by leaking the debugger list and its mutex. <rdar://problem/26372169> llvm-svn: 270869
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-41/+41
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Don't let two threads call Debugger::Clear simultaneously.Greg Clayton2016-05-041-24/+39
| | | | | | | | We don't want a mutex in debugger as it will cause A/B locking issues with the lldb_private::Target's mutex, but we do need to stop two threads from doing Debugger::Clear at the same time. We have seen issues with this with the C++ global destructor chain where the global debugger list is being destroyed and the Debugger::~Debugger() is calling it while another thread was in the middle of running that function. <rdar://problem/26098913> llvm-svn: 268563
* Corrected wording of REPL not available messaging (contained a repeated word ↵Kate Stone2016-04-211-1/+1
| | | | | | and lacked clarity.) llvm-svn: 266941
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-071-12/+13
| | | | | | | | | | | | | | to each other. This should remove some infrequent teardown crashes when the listener is not the debugger's listener. Processes now need to take a ListenerSP, not a Listener&. This required changing over the Process plugin class constructors to take a ListenerSP, instead of a Listener&. Other than that there should be no functional change. <rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39 llvm-svn: 262863
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-021-109/+100
| | | | | | other minor fixes. llvm-svn: 262450
* [LLDB] Switch to assembly view if source is movedMohit K. Bhakkad2015-12-031-4/+5
| | | | | | | | Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
* Fix error handling when there are no REPLs installed.Sean Callanan2015-10-211-0/+22
| | | | | | | | Before, in the absence of any configured REPLs, LLDB would act as if there were multiple possible REPL options, whereas actually no REPL language is supported. Now we make a better error. llvm-svn: 250931
* Fixed version of r250913, which actually implements all the static functions.Sean Callanan2015-10-211-5/+0
| | | | | | Thanks to Siva Chandra and Oleksiy Vyalov for pouncing on this. llvm-svn: 250928
* Revert "Made the REPL choose a default language if only one REPL can be chosen."Siva Chandra2015-10-211-0/+5
| | | | | | | | | | | | Summary: This reverts commit babd6dd74e316b1fcd9d171d7d8c83845d51a487. Reviewers: spyffe Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13952 llvm-svn: 250927
* Made the REPL choose a default language if only one REPL can be chosen.Sean Callanan2015-10-211-5/+0
| | | | | | This requires REPLs to enumerate the languages they support. llvm-svn: 250913
* When target is NULL, provide a debugger so that REPLs can use that to createSean Callanan2015-10-211-1/+1
| | | | | | their own target. llvm-svn: 250869
* Added support for the "--repl" argument to LLDB. Sean Callanan2015-10-201-0/+34
| | | | | | | | | This makes LLDB launch and create a REPL, specifying no target so that the REPL can create one for itself. Also added the "--repl-language" option, which specifies the language to use. Plumbed the relevant arguments and errors through the REPL creation mechanism. llvm-svn: 250773
* Added the concept of a Read-Eval-Print-Loop to LLDB.Sean Callanan2015-10-191-0/+72
| | | | | | | | | | | | | | | | A REPL takes over the command line and typically treats input as source code. REPLs can also do code completion. The REPL class allows its subclasses to implement the language-specific functionality without having to know about the IOHandler-specific internals. Also added a PluginManager-based way of getting to a REPL given a language and a target. Also brought in some utility code and expression options that are useful for REPLs, such as line offsets for expressions, ANSI terminal coloring of errors, and a few IOHandler convenience functions. llvm-svn: 250753
* Reduce inclusion of clang headers.Bruce Mitchener2015-09-181-3/+0
| | | | | | | | | | | | | | Summary: With the recent changes to separate clang from the core structures of LLDB, many inclusions of clang headers can be removed. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12954 llvm-svn: 248004
* Fix debugger shutdown when Python interpreter is loaded.Oleksiy Vyalov2015-09-081-1/+5
| | | | | | http://reviews.llvm.org/D12683 llvm-svn: 247023
* Purge a few places where *LanguageRuntime.h was being used when it Jim Ingham2015-09-031-2/+1
| | | | | | wasn't needed. llvm-svn: 246744
* First part of an attempt to indicate to the user when they are Jason Molenda2015-07-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | debugging optimized code. Adds new methods on Function/SBFunction to query whether a given function is optimized. Adds a new function.is-optimized format entity and changes the default frame-format to append "[opt]" if the function was built with optimization. The only indication that a binary was built with optimization that we have right now is the presence of the DW_AT_APPLE_optimized attribute (DW_FORM_flag value 1) in the DW_TAG_compile_unit. The absence of this flag may mean that the compile_unit was not compiled with optimization, or it may mean that the producer does not generate this attribute. Currently this only works for dSYM debugging. When we create the CompileUnit with dwarf-in-.o-file debugging we don't have the attribute value yet so it's not set. I need to find the flag value when we do start to read the .o file DWARF and set the CompileUnit's status at that point - but haven't done it yet. I'm also going to add a mechanism for issuing warnings to users such that they're only issued once in a debug session and there is away for users to suppress these warnings altogether via .lldbinit file settings. But I want to get this changeset committed now that it's at a useful state. <rdar://problem/19281172> llvm-svn: 243508
* 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
* Make log options uniform betwwen lldb-platform and lldb-gdbserverTamas Berghammer2015-05-271-29/+1
| | | | | | | | | | This change also get rid of an unused Debugger instance in GDBRemoteCommunicationServerLLGS and the command interpreter from lldb-platform what was used only for enabling logging. Differential revision: http://reviews.llvm.org/D9876 llvm-svn: 238319
* Improve LLDB prompt handlingPavel Labath2015-05-271-111/+77
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix we have in for this is not working all the time and is introducing unnecessary delays. This change does: - Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to lldb-dev. - coordinates printing of asynchronous text with the iohandlers. This is also based on a (different) Greg's patch, but I have added stronger synchronization to it to avoid races. Together, these changes solve the prompt problem for me on linux (both with and without libedit). I think they should behave similarly on Mac and FreeBSD and I think they will not make matters worse for windows. Test Plan: Prompt comes out alright. All tests still pass on linux. Reviewers: clayborg, emaste, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9823 llvm-svn: 238313
* Fix Debugger::HandleProcessEvent in case when ProcessIOHandler doesn't existIlia K2015-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously the Debugger::HandleProcessEvent hid a top IOHandler if the process's IOHandler was inactive and later refreshed it. Usually the IOHandler.Refresh() prints the (lldb) prompt. The problem was in case of iOS remote platform when trying to execute 'command source' command. On this platform the process's IOHandler is empty, therefore the Debugger::HandleProcessEvent hid a top IOHandler and later refreshed it. So that the (lldb) prompt was printed with a program output in mixed order: was: ``` longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong longlonglonglonglonglonglonglonglonglonglonglonglonglonglon(lldb) glonglonglonglonglonglonglonglonglonglonglonglong string ``` now: ``` longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong longlonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglonglong longlonglonglonglonglonglonglonglong string ``` Reviewers: zturner, jingham, clayborg Reviewed By: clayborg Subscribers: lldb-commits, jingham, zturner, clayborg Differential Revision: http://reviews.llvm.org/D8929 llvm-svn: 234517
* Rework LLDB system initialization.Zachary Turner2015-03-311-30/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support for truncate/append on log filesPavel Labath2015-03-201-1/+6
| | | | | | | | | | | | | | | Summary: Presently, if a log file already exists, lldb simply starts overwriting bits of it, without truncating or anything. This patch makes it use eFileOptionFileTruncate by default. It also adds an --append option, which will append to the file without truncating. A test is included. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8450 llvm-svn: 232801
* Move LLDB initialization/shutdown to Initialization.Zachary Turner2015-03-191-24/+5
| | | | | | | | | | | | | | | | This creates a new top-level folder called Initialization which is intended to hold code specific to LLDB system initialization. Currently this holds the Initialize() and Terminate() functions, as well as the fatal error handler. This provides a means to break the massive dependency cycle which is caused by the fact that Debugger depends on Initialize and Terminate which then depends on the entire LLDB project. With this structure, it will be possible for applications to invoke lldb_private::Initialize() directly, and have that invoke Debugger::Initialize. llvm-svn: 232768
* Add Debugger::InitializeForLLGS to allow ref counted LLGS initialization.Robert Flack2015-03-101-3/+22
| | | | | | | | | | | | | | After http://reviews.llvm.org/D8133 landed as r231550 process launch on remote platform stopped working. This adds Debugger::InitializeForLLGS and tracks whether one or both of Initialize and InitializeForLLGS have been called, calling only the corresponding lldb_private::Terminate* methods as necessary. Since lldb_private::Terminate calls lldb_private::TerminateForLLGS, the latter method may be called twice if Initialize was called for both however the terminate methods ensure they are only called once after being initialized. This still maintains the reduced binary size, though it does now technically link in lldb_private::Terminate on lldb-server even though this should never be called. This should resolve the issue raised in http://reviews.llvm.org/D8133 where Debugger::Terminate assumed that there were 0 references to debugger and terminated early. Differential Revision: http://reviews.llvm.org/D8183 llvm-svn: 231808
* Add Utility/ModuleCache class and integrate it with PlatformGDBRemoteServer ↵Oleksiy Vyalov2015-03-101-0/+4
| | | | | | | | - in order to allow modules caching from remote targets. http://reviews.llvm.org/D8037 llvm-svn: 231734
* Further reduce header footprint of Debugger.h.Zachary Turner2015-03-041-0/+1
| | | | llvm-svn: 231202
* Fix a typo Debugger::ExecuteIOHanders to Debugger::ExecuteIOHandlers.Siva Chandra2015-02-261-2/+2
| | | | | | | | | | | | | | Test Plan: Build LLDB. Reviewers: zturner, vharron, clayborg Reviewed By: vharron, clayborg Subscribers: jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D7894 llvm-svn: 230663
* Change the default disassembly format again. First attempt atJason Molenda2015-02-131-1/+15
| | | | | | | | | | | | | | | | changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
* Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity ↵Greg Clayton2015-02-041-1702/+36
| | | | | | | | | | | | | | | | | | | class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
* Three related changes to help:Kate Stone2015-01-151-0/+12
| | | | | | | | | | | | | | | | The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning. The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably. Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands. <rdar://problem/17751929> <rdar://problem/16953815> <rdar://problem/16953841> <rdar://problem/16930173> <rdar://problem/16879028> llvm-svn: 226068
* Add the ability to set breakpoints with conditions, commands, etc,Jim Ingham2014-12-061-5/+9
| | | | | | | | | | | | | | in the "dummy-target". The dummy target breakpoints prime all future targets. Breakpoints set before any target is created (e.g. breakpoints in ~/.lldbinit) automatically get set in the dummy target. You can also list, add & delete breakpoints from the dummy target using the "-D" flag, which is supported by most of the breakpoint commands. This removes a long-standing wart in lldb... <rdar://problem/10881487> llvm-svn: 223565
* Fix the behavior of ${current-pc-arrow} in the default disassemblyJason Molenda2014-12-021-7/+8
| | | | | | | | | | | | format for the not-current-stack-frame. This was causing test/functionalities/inferior-assert to fail. Also document the new additions to the format specifications used in the disassembly-format changes to formats.html. <rdar://problem/19102757> llvm-svn: 223096
* lldb can deadlock when launched with an non-existing executable:Greg Clayton2014-12-011-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | % lldb /bin/nonono (lldb) target create "/bin/nonono" error: unable to find executable for '/usr/bin/nonono' <deadlock> The problem was the initial commands 'target create "/bin/nonono"' were put into a pipe and the command interpreter was being run with: void CommandInterpreter::RunCommandInterpreter(bool auto_handle_events, bool spawn_thread, CommandInterpreterRunOptions &options) { // Always re-create the command intepreter when we run it in case // any file handles have changed. bool force_create = true; m_debugger.PushIOHandler(GetIOHandler(force_create, &options)); m_stopped_for_crash = false; if (auto_handle_events) m_debugger.StartEventHandlerThread(); if (spawn_thread) { m_debugger.StartIOHandlerThread(); } else { m_debugger.ExecuteIOHanders(); if (auto_handle_events) m_debugger.StopEventHandlerThread(); } } If "auto_handle_events" was set to true and "spawn_thread" was false, we would execute: m_debugger.StartEventHandlerThread(); m_debugger.ExecuteIOHanders(); m_debugger.StopEventHandlerThread(); The problem was there was no synchonization in Debugger::StartEventHandlerThread() to ensure the event handler was listening to events and the the call to "m_debugger.StopEventHandlerThread()" would do: void Debugger::StopEventHandlerThread() { if (m_event_handler_thread.IsJoinable()) { GetCommandInterpreter().BroadcastEvent(CommandInterpreter::eBroadcastBitQuitCommandReceived); m_event_handler_thread.Join(nullptr); } } The problem was that the event thread might not be listening for the CommandInterpreter::eBroadcastBitQuitCommandReceived event yet. The solution is to make sure the Debugger::DefaultEventHandler() is listening to events before we return from Debugger::StartEventHandlerThread(). Once we have this synchonization we remove the race condition. This fixes radar: <rdar://problem/19041192> llvm-svn: 223083
OpenPOWER on IntegriCloud