summaryrefslogtreecommitdiffstats
path: root/lldb/tools
Commit message (Collapse)AuthorAgeFilesLines
...
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-012-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling: rnb_err_t RNBRemote::HandlePacket_stop_process (const char *p) { if (!DNBProcessInterrupt(m_ctx.ProcessID())) HandlePacket_last_signal (NULL); return rnb_success; } In the call to DNBProcessInterrupt we did: nub_bool_t DNBProcessInterrupt(nub_process_t pid) { MachProcessSP procSP; if (GetProcessSP (pid, procSP)) return procSP->Interrupt(); return false; } This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response. To fix this I did the following: 1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines 2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen 3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply. 5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response. 6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() 7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process. The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (incorrect extra stop reply packet) --> c <-- OK (response from z0 packet) Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets) <-- OK -- (we are back on track as this is a valid response to z0) ... As time goes on we should add more packet validators. <rdar://problem/22859505> llvm-svn: 265086
* Revert the "build fix" in r264104Pavel Labath2016-03-291-4/+0
| | | | | | | | this was needed because lldb-mi temporarily contained references to private lldb symbols (lldb_private namespace), which it shouldn't have. The situation has since been rectified and this wasn't the right fix anyway, since it can lead to funny ODR violations. llvm-svn: 264733
* Update the INFOPLIST_FILE setting in the xcode project fileJason Molenda2016-03-241-1/+1
| | | | | | | | so that the lldb command line binary's version #'s are updated correctly. <rdar://problem/25346711> llvm-svn: 264353
* Reverted a change in r264074 that made lldb-mi use lldb_private APIs.Sean Callanan2016-03-221-1/+2
| | | | | | | | FileSystem::Fopen is a lldb_private API, but lldb-mi uses only the public API. Depending on lldb_private APIs makes Xcode builds fail. I reverted the portion of r264074 that added such a dependency. llvm-svn: 264113
* [lldb-mi] Uncomment a line in CMakeLists.txt to make linux build happy.Siva Chandra2016-03-221-1/+1
| | | | | | | | | | Reviewers: zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18377 llvm-svn: 264104
* Unicode support on Win32.Zachary Turner2016-03-224-39/+66
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Delete the custom implementation of signal() on Windows.Zachary Turner2016-03-186-113/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The Windows SDK provides a version of signal() that is much more limited compared to other platforms. It only supports about 5-6 signal values. LLDB uses signals for a number of things, most notably to handle Ctrl+C so we can gracefully shut down. The portability solution to this on Windows has been to provide a hand-rolled implementation of `signal` using the name `signal` so that you could write code that simply calls signal directly and it would work. But this introduces a multiply defined symbol with the builtin version and depending on how you included header files, you could get yourself into a situation where you had linker errors. To make matters worse, it led to a ton of compiler warnings. Worst of all though is that this custom implementation of signal was, in fact, identical for the purposes of handling Ctrl+C as the builtin implementation of signal. So it seems to have literally not been serving any useful purpose. This patch deletes all the custom signal() functions for Windows, and includes the signal.h system header, so that any calls to signal now go to the actual version provided by the Windows SDK. Differential Revision: http://reviews.llvm.org/D18287 llvm-svn: 263858
* Added a break statement that was needed. Caught by clang's unannotated case ↵Greg Clayton2016-03-181-1/+2
| | | | | | fall through warning. llvm-svn: 263830
* Bump the lldb version # in the xcode project files fromJason Molenda2016-03-151-19/+19
| | | | | | 350.99.0 to 360.99.0. llvm-svn: 263529
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* Removed unused functions.Greg Clayton2016-02-242-105/+0
| | | | llvm-svn: 261768
* [linux] Remove all traces of signalfd(2)Pavel Labath2016-02-231-7/+0
| | | | | | | | | | | | | | | Summary: Signalfd is not used in the code anymore, and given that the same functionality can be achieved with the new MainLoop class, it's unlikely we will need it in the future. Remove all traces of it. Reviewers: tberghammer, ovyalov Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D17510 llvm-svn: 261631
* This patch stops lldb from loading a .lldbinit file from the currentJason Molenda2016-02-192-10/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | working directory by default -- a typical security problem that we need to be more conservative about. It adds a new target setting, target.load-cwd-lldbinit which may be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit) or warn (warn if there is a $cwd/.lldbinit and don't read it). The default is set to warn. If this is met with unhappiness, we can look at changing the default to true (to match current behavior) on a different platform. This does not affect reading of ~/.lldbinit - that will still be read, as before. If you run lldb in your home directory, it will not warn about the presence of a .lldbinit file there. I had to add two SB API - SBHostOS::GetUserHomeDirectory and SBFileSpec::AppendPathComponent - for the lldb driver code to be able to get the home directory path in an OS neutral manner. The warning text is There is a .lldbinit file in the current directory which is not being read. To silence this warning without sourcing in the local .lldbinit, add the following to the lldbinit file in your home directory: settings set target.load-cwd-lldbinit false To allow lldb to source .lldbinit files in the current working directory, set the value of this variable to true. Only do so if you understand and accept the security risk. <rdar://problem/24199163> llvm-svn: 261280
* Silence some clang warningsSaleem Abdulrasool2016-02-151-1/+2
| | | | | | Silences -Wmissing-brace and -Wformat-pedantic warnings from clang on Linux. NFC. llvm-svn: 260914
* Add new option to lldb-server to display its versionTamas Berghammer2016-02-101-15/+21
| | | | llvm-svn: 260366
* Add a missing break.Jim Ingham2016-02-101-1/+1
| | | | llvm-svn: 260345
* If we set the DYLD_INSERT_LIBRARIES environment variable when launching ↵Greg Clayton2016-02-091-0/+4
| | | | | | debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't pass this environment variable on to any child processes. llvm-svn: 260284
* Show real error message in -data-evaluate-expressionEugene Leviant2016-02-082-3/+8
| | | | llvm-svn: 260082
* Have lldb-server log the timestamp in its log messagesPavel Labath2016-02-081-1/+1
| | | | llvm-svn: 260078
* Fix crash in lldb-mi when stack variable name is nullptr. This always ↵Eugene Leviant2016-01-291-1/+6
| | | | | | happens when execution stops in try scope with unnamed catch clause llvm-svn: 259189
* Fix linking of lldb-server with BUILD_SHARED_LIBSPavel Labath2016-01-291-16/+11
| | | | | | | | | | | | | | | | | | | | Summary: The BUILD_SHARED_LIBS branch of lldb-server link flags was hopelessly broken, at least since we started restricting the symbols exported by liblldb. lldb-server depends on symbols from the lldb_private namespace, so it cannot link to the public interface of liblldb. Instead I make it link to the individual libraries constituting liblldb, just like it does in the !BUILD_SHARED_LIBS case. This does not make the BUILD_SHARED_LIBS build of lldb fully functional yet, due to the way liblldb dependencies are managed, but it's a step in that direction. Reviewers: zturner, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16678 llvm-svn: 259188
* add back an Xcode-specific Makefile for header installationTodd Fiala2016-01-281-0/+23
| | | | llvm-svn: 259102
* Remove autoconf support from source directories.Eugene Zelenko2016-01-2810-297/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* A while back in revison 244716 we added support for getting the host OS ↵Greg Clayton2016-01-281-8/+2
| | | | | | | | version info from debugserver. We added keys to "qHostInfo" that were "osmajor", "osminor" and "ospatch", but no one ever parsed those, so I am removing them from debugserver. We accidentally also added a "version" key to qHostInfo instead of "os_version". So now we need to support both "version" and "os_version" in qHostInfo since we have debugserver binaries out in the wild that support this old packet type. I have updated debugserver ot use the correct "os_version" for future compatability or correctness. <rdar://problem/24378699> llvm-svn: 259003
* Fixed some #ifdefs. We were erroneously not supporting certain simulators.Sean Callanan2016-01-201-2/+2
| | | | | | | | We had some #ifdefs that were looking for the wrong #defines and as a result debugserver didn't have support for certain simulators. This patch resolves the problem. llvm-svn: 258365
* Changes to lldb and debugserver to reduce extraneous memory readsJason Molenda2016-01-122-38/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | at each public stop to improve performance a bit. Most of the information lldb needed was already in the jThreadsInfo response; complete that information and catch a few cases where we could still fall back to getting the information via discrete memory reads. debugserver adds 'associated_with_dispatch_queue' and 'dispatch_queue_t keys to the jThreadsInfo response for all the threads. lldb needs the dispatch_queue_t value. And associated_with_dispatch_queue helps to identify which threads definitively don't have any queue information so lldb doesn't try to do memory reads to get that information just because it was absent in the jThreadsInfo response. Remove the queue information from the questionmark (T) packet. We'll get the information for all threads via the jThreadsInfo response - sending the information for the stopping thread (on all the private stops, plus the less frequent public stop) was unnecessary information being sent over the wire. SystemRuntimeMacOSX will try to get information about queues by asking the Threads for them, instead of reading memory. ProcessGDBRemote changes to recognize the new keys being sent in the jThreadsInfo response. Changes to ThreadGDBRemote to track the new information. Also, when a thread is marked as definitively not associated with a libdispatch queue, don't fall back to the system runtime to try memory reads to find the queue name / kind / ID etc. <rdar://problem/23309359> llvm-svn: 257453
* In the questionmark packet ("T"), print the "threads:" and "thread-pcs:"Jason Molenda2016-01-081-30/+30
| | | | | | | | keys before we print the libdispatch queues keys (qname, qkind, qserialnum) to make it easier to read the packet by hand. No function difference, just reordering the keys in the output. llvm-svn: 257229
* Change the key name for the libdispatch queue serial number fromJason Molenda2016-01-081-2/+2
| | | | | | | | | "qserial" to "qserialnum" because "qserial" looks a lot like the queue type (either 'serial' or 'concurrent') and can be confusing to read through. debugserver passes these up either in the questionmark ("T") packet, or in the response to the jThreadsInfo packet. llvm-svn: 257121
* Apply missed changes from svn r256863 "Add support for "source info" and use ↵Dawn Perchik2016-01-061-2/+2
| | | | | | | | | it to fix MI's -symbol-list-lines.". Patch is part of Differential Revision: http://reviews.llvm.org/D15593 Differential Revision: http://reviews.llvm.org/D15904 llvm-svn: 256877
* Add support for "source info" and use it to fix MI's -symbol-list-lines.Dawn Perchik2016-01-051-18/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support the command 'source info' as follows: (lldb) help source info Display source line information (as specified) based on the current executable's debug info. Syntax: source info <cmd-options> Command Options Usage: source info [-c <count>] [-s <shlib-name>] [-f <filename>] [-l <linenum>] [-e <linenum>] source info [-c <count>] [-s <shlib-name>] [-n <symbol>] source info [-c <count>] [-a <address-expression>] -a <address-expression> ( --address <address-expression> ) Lookup the address and display the source information for the corresponding file and line. -c <count> ( --count <count> ) The number of line entries to display. -e <linenum> ( --end-line <linenum> ) The line number at which to stop displaying lines. -f <filename> ( --file <filename> ) The file from which to display source. -l <linenum> ( --line <linenum> ) The line number at which to start the displaying lines. -n <symbol> ( --name <symbol> ) The name of a function whose source to display. -s <shlib-name> ( --shlib <shlib-name> ) Look up the source in the given module or shared library (can be specified more than once). For example: (lldb) source info --file x.h Lines for file x.h in compilation unit x.cpp in `x [0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10 [0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10 The new options are used to fix the MI command: -symbol-list-lines <file> which didn't work for header files because it called: target modules dump line-table <file> which only dumps line tables for a compilation unit. The patch also fixes a bug in the error reporting when no files were supplied to the command. Previously you'd get: (lldb) target modules dump line-table error: Syntax: error: no source filenames matched any command arguments Now you get: error: file option must be specified. Reviewed by: clayborg, jingham, ki.stfu Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15593 llvm-svn: 256863
* Wrap Notes in --help output to 80 columnsEd Maste2015-12-161-7/+13
| | | | llvm-svn: 255774
* Add a new "thread-pcs" key-value pair to the T packet response fromJason Molenda2015-12-151-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | debugserver. thread-pcs has a comma separated list of base 16 addresses - the current pc value for every thread in the process. It is a partner of the "threads:" key where a list of thread IDs is given. The pc values in thread-pcs correspond one-to-one with the thread IDs in the threads list. This is a part of performance work. When lldb is instruction stepping / fast stepping over a range of addresses for e.g. a "next" command, and it steps in to another function, lldb will put a breakpoint on the return address and continue the process. Before it calls continue, it calls Thread::SetupForResume on all the threads, and SetupForResume needs to get the current pc value for every thread to see if any are at a breakpoint site. The result is that issuing a "c" continue requires that we send "read pc register" packets for every thread. We may do this sequence of step-into-function / continue-to-get-out many times for a single user-visible "next" or "step" command, and with highly multithreaded programs, we are sending many extra packets to get all the thread values. I looked at including this data in the "jstopinfo" JSON that we already have in the T packet. But there are three problems that would make this increase the size of the T packet significantly. First, numbers in JSON are base 10. Second, a proper JSON would have something like "thread_pcs": { "34224331112":383772734222, ...} for thread-id 34224331112 and pc 383772734222 - so we're including a whole extra copy of the thread id in addition to the pc. Third, the JSON text is hex-ascii'fied so the size of it is doubled. In one example, threads:585db8,585dc7,585dc8,585dc9,585dca,585dce;thread-pcs:100001400,7fff8badc6de,7fff8badcff6,7fff8badc6de,7fff8badc6de,7fff8badc6de; The "thread-pcs" adds 86 characters - 136 characters for both threads and thread-pcs. Doing this in JSON would look like threads={"5791160":4294972416,"5791175":140735536809694,"5791176":140735536812022,"5791177":140735536809694,"5791178":140735536809694,"5791182":140735536809694} or 160 characters -- or 320 characters once it is hex-asciified. Given that it's 86 characters vrs 320, I went with the old style approach. I've seen real world programs that have up to 60 threads in them, so this could result in vastly larger packets if it was all done in the JSON with hex-ascii expansion. If we had an all-JSON T packet, where we didn't need to hex-ascii encode anything, that would have been the better approach. But we'd already have a list of threads in JSON at that point so the additional text wouldn't be too bad. I'm working on finishing the patches to lldb to use this data; will commit those once I've had a chance to test them more. But I wanted to commit the debugserver bits which are more straightforward. <rdar://problem/21963031> llvm-svn: 255711
* When supplying memory to expedite the unwinds in the T packet,Jason Molenda2015-12-121-1/+1
| | | | | | | | | include two stack frames worth of unwind information instead of just one -- the unwinder is trying to fetch two stack frames in more instances now and we're sending extra memory reads resulting in a performance degredation while stepping. llvm-svn: 255417
* Modify "platform connect" to connect to processes as wellTamas Berghammer2015-12-081-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
* Allow variable names to be quoted with -var-list-childrenChuck Ries2015-12-071-1/+1
| | | | | | | | Allow both '-var-list-children var0' and '-var-list-children "var0"' to be used with the -var-list-children command. GDB MI allows for this and it is necessary if the variable name contains spaces, such as var5.std::_Vector_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<cahr> > > >. Differential Revision: http://reviews.llvm.org/D15168 llvm-svn: 254941
* test commit.Chuck Ries2015-12-071-1/+1
| | | | llvm-svn: 254924
* Add more autotools/gmake NetBSD glueBruce Mitchener2015-11-153-5/+3
| | | | | | | | | | | | | | Summary: This diff approaches building the project natively on NetBSD with the autoconf/gmake framework. Patch by Kamil Rytarowski. Thanks! Reviewers: emaste, clayborg Subscribers: tberghammer, joerg, brucem, lldb-commits Differential Revision: http://reviews.llvm.org/D14531 llvm-svn: 253153
* Add more NetBSD platform glue for lldbBruce Mitchener2015-11-072-2/+2
| | | | | | | | | | | | | | | | | | Summary: These changes are still incomplete, but we are almost there. Changes: - CMake and gmake code - SWIG code - minor code additions Reviewers: emaste, joerg Subscribers: youri, akat1, brucem, lldb-commits, joerg Differential Revision: http://reviews.llvm.org/D14042 llvm-svn: 252403
* Add support for one API used to detect if a processJason Molenda2015-11-051-0/+12
| | | | | | | | | | is running under System Integrity Protection on Mac OS X 10.11. The rootless_allows_task_for_pid() spi (see debugserver RNBRemote.cpp) is the final SPI that is used for this - should add support for that too at some point. llvm-svn: 252228
* Squelch a silly warning regarding an extra 'default' in 'case'Ramkumar Ramachandra2015-11-031-39/+38
| | | | | | | | | | | | Let the editor also clean up whitespace for that file. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13816 llvm-svn: 251979
* Handle the options and parameters separator in every MI commandHafiz Abid Qadeer2015-11-024-3/+4
| | | | | | | | | | | | | | | | | | | Summary: As per the following link, the "--" separator can appear between the options and parameters of any MI command. Previously this separator was only handled by the `-data-disassemble` MI command. I have moved the relevant code into `CMICmdBase` so that any MI command can handle the aforementioned separator. https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax Reviewers: ki.stfu Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14197 llvm-svn: 251793
* Fix Clang-tidy modernize-use-override warnings in include/lldb/Expression, ↵Eugene Zelenko2015-10-314-71/+39
| | | | | | source/Expression and tools/lldb-mi; other minor fixes. llvm-svn: 251730
* Remove 2 lines missed in earlier commit (r251636).Hafiz Abid Qadeer2015-10-301-2/+0
| | | | llvm-svn: 251704
* Better handle the arguments common to all MI commands.Hafiz Abid Qadeer2015-10-2919-141/+66
| | | | | | | | | | | | | | | | | | | | | | | | Summary: I observed that eclipse was passing --thread-group for many other commands then we are currently handling. Looking at the MI documentation, the following link states that each MI command accept the --thread and --frame option. Looking at the GDB implementation, it seems that apart from these 2, --thread-group is also handled the same way. https://sourceware.org/gdb/onlinedocs/gdb/Context-management.html#Context-management So instead of handling those arguments in every comamnds, I have moved them into the base class and removed them from elsewhere. Now any command can use these arguments. The patch seems big but most of the changes are mechanical. Reviewers: ki.stfu Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14177 llvm-svn: 251636
* Rename argdumper to lldb-argdumperTodd Fiala2015-10-291-3/+3
| | | | | | http://reviews.llvm.org/D14169 llvm-svn: 251616
* Xcode suggested enabling a "no common blocks" warningJason Molenda2015-10-292-9/+22
| | | | | | | (whatever that is) and wanted to clean up some duplicated entries in the project files. llvm-svn: 251586
* Make lldb-gdbserver to take explicit socket scheme as command line argument.Oleksiy Vyalov2015-10-283-2/+24
| | | | | | http://reviews.llvm.org/D14126 llvm-svn: 251547
* Add Socket::Create factory method which uses socket protocol to find an ↵Oleksiy Vyalov2015-10-272-21/+77
| | | | | | | | appropriate implementation class. http://reviews.llvm.org/D14085 llvm-svn: 251417
* Remove some unnecessary macosx.internal SDK settings inJason Molenda2015-10-251-9/+9
| | | | | | the debugserver xcode project file. llvm-svn: 251221
OpenPOWER on IntegriCloud