summaryrefslogtreecommitdiffstats
path: root/lldb/tools
Commit message (Collapse)AuthorAgeFilesLines
* Switch over to using socketpair for local debugserver connections as they ↵Greg Clayton2016-08-121-1/+46
| | | | | | | | | | | | | | | | are twice as fast as TCP sockets (on macOS at least). This change opens a socket pair and passes the second socket pair file descriptor down to the debugserver binary using a new option: "--fd=N" where N is the file descriptor. This file descriptor gets passed via posix_spawn() so that there is no need to do any bind/listen or bind/accept calls and eliminates the hanshake unix socket that is used to pass the result of the actual port that ends up being used so it can save time on launch as well as being faster. This is currently only enabled on __APPLE__ builds. Other OSs should try modifying the #define from ProcessGDBRemote.cpp but the first person will need to port the --fd option over to lldb-server. Any OSs that enable USE_SOCKETPAIR_FOR_LOCAL_CONNECTION in their native builds can use the socket pair stuff. The #define is Apple only right now, but looks like: #if defined (__APPLE__) #define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1 #endif <rdar://problem/27814880> llvm-svn: 278524
* Undo usage of LLVM macros in debugserverTodd Fiala2016-08-101-2/+2
| | | | | | | We don't take a dependency on LLVM in debugserver. This was failing to compile before. llvm-svn: 278190
* Delete Host/windows/win32.hZachary Turner2016-08-092-5/+5
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* Remove CFData from the xcodeproj as wellEnrico Granata2016-08-091-8/+0
| | | | llvm-svn: 278158
* [debugserver] Delete CFData.{h,cpp}, since they appear to be dead (NFCI)Vedant Kumar2016-08-094-114/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D23070 llvm-svn: 278142
* Remove Android.hPavel Labath2016-08-081-1/+2
| | | | | | | It only contained a reimplementation of std::to_string, which I have replaced with usages of pre-existing llvm::to_string (also, injecting members into the std namespace is evil). llvm-svn: 278000
* [lldb] Delete dead, infinitely-recursive code (NFC)Vedant Kumar2016-08-012-12/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D22985 llvm-svn: 277351
* Fix -break-insert not working when using absolute paths (MI)Ilia K2016-07-293-1/+27
| | | | | | | | | | | | | | Summary: When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters. This fixes https://llvm.org/bugs/show_bug.cgi?id=28709 Patch from malaperle@gmail.com Reviewers: clayborg, ki.stfu Subscribers: lldb-commits, ki.stfu Differential Revision: https://reviews.llvm.org/D22902 llvm-svn: 277117
* Add a new DynamicLoader plugin that uses SPI that are in developmentJason Molenda2016-07-211-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for the fall (northern hemisphere) 2016 Darwin platforms to learn about loaded images, instead of reading dyld internal data structures. These new SPI don't exist on older releases, and new packets are needed from debugserver to use them (those changes are already committed). I had to change the minimum deployment target for debugserver in the xcode project file to macOS 10.10 so that debugserver will use the [[NSProcessInfo processInfo] operatingSystemVersion] call in MachProcess::GetOSVersionNumbers to get the operarting system version # -- this API is only available in macOS 10.10 and newer ("OS X Yosemite", released Oct 2014). If we have many people building llvm.org lldb on older systems still, we can back off on this for the llvm.org sources. There should be no change in behavior with this commit, either to older darwin systems or newer darwin systems. For now the new DynamicLoader plugin is never activated - I'm forcing the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI. I'll remove that unconditional use of the old plugin soon, so the newer plugin is used on the newest Darwin platforms. <rdar://problem/25251243> llvm-svn: 276254
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* Fix -break-enable/-break-disable commands (MI)Ilia K2016-07-141-23/+3
| | | | | | | | | | | | | * Previously -break-enable mistakenly set BP's enabled flag to false. * These commands print fake =breakpoint-modified messages, what's not needed anymore because that events are come in normal way. * Add tests for -break-enable/-break-disable commands Initial patch from xuefangliang@hotmail.com. The test case was improved by me. Differential Revision: http://reviews.llvm.org/D21757 llvm-svn: 275381
* Try to fix the OSX build with old SDK after r274725Tamas Berghammer2016-07-071-2/+12
| | | | llvm-svn: 274743
* debugserver will now report the minimum version load commandJason Molenda2016-07-072-0/+47
| | | | | | | | | | | | os name and version # from the mach-o binary as it scans the header/load commands from memory and sends the details back in the jGetLoadedDynamicLibrariesInfos response. lldb isn't using these fields yet but I have a suspicion I'm going to need them soon. <rdar://problem/25251243> llvm-svn: 274725
* Add support to debugserver for some new ways to interact with dyldJason Molenda2016-07-076-174/+611
| | | | | | | | | | | | to find the solibs loaded in a process. Support two new ways of sending the jGetLoadedDynamicLibrariesInfos packet to debugserver and add a new jGetSharedCacheInfo packet. Update the documentation for these packets as well. The changes to lldb to use these will be a separate commit. <rdar://problem/25251243> llvm-svn: 274718
* Remove SIGPIPE handler in LLGSPavel Labath2016-07-041-20/+1
| | | | | | | It is sufficient to set the handeler to SIG_IGN, to get the desired behaviour. Also, the handler calling a lot of signal-unsafe functions. llvm-svn: 274499
* Remove platform plugins from lldb-serverPavel Labath2016-06-291-73/+1
| | | | | | | | | | | | | | | | | | | Summary: This removes the last usage of Platform plugins in lldb-server -- it was used for launching child processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always running on the host). Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and architecture). Reviewers: clayborg Subscribers: tberghammer, danalbert, srhines, lldb-commits Differential Revision: http://reviews.llvm.org/D20440 llvm-svn: 274125
* 64-bit LEB values are not always correctly decoded due to a casting issue, ↵Greg Clayton2016-06-281-2/+2
| | | | | | | | now they are. <rdar://problem/27002247> llvm-svn: 274037
* Fix the "Release" build on MacOSX for debugserver. Extra bad include paths ↵Greg Clayton2016-06-211-1/+0
| | | | | | were making things not build due to header file issues with stdio.h. llvm-svn: 273306
* Change the "debugserver-mini" target (a version of debugserverJason Molenda2016-06-212-21/+40
| | | | | | | | | | | | | | | | | | which doesn't like against all the extra UI frameworks on ios) so it now generates a binary called "debugserver-nonui" and puts it in /usr/local/bin instead of /Developer/usr/bin. Add some cruft to RNBDefs.h to get the version number (provided by Xcode at build time) with either the name "debugserver" or "debugserver_nonui" as appropriate. Add the "debugserver-mini" target to the top level "ios" target in lldb xcode project file, so this nonui debugserver will be built along with the normal lldb / debugserver. <rdar://problem/24730789> llvm-svn: 273236
* Add support for using armv7 compact unwind informationJason Molenda2016-06-071-2/+2
| | | | | | | | | | | | | | | as an asynchronous unwind plan source. Two small fixes to the compact unwind dumper tool for armv7 encodings. A change to DWARFCallFrameInfo to strip the 0th bit on addresses in eh_frame sections when armv7. In the clang generated examples I have, the 0th bit is set for thumb functions and that's causing the unwinder to pick the wrong function for eh_frame info. llvm-svn: 271970
* Add armv7 compact unwind printing to the compact-unwind-dumper.c toolJason Molenda2016-06-041-0/+199
| | | | | | as a prototype for adding armv7 compact unwind reading to lldb. llvm-svn: 271774
* [cmake] Add ability to customize (and skip) debugserver codesignPavel Labath2016-05-261-23/+25
| | | | | | | | | | | | | | | | | | Summary: This adds the ability to customize the debugserver codesign process via cmake cache variable. The user can set the codesign indentity (with the default being the customary lldb_codesign), and if the identity is set to a empty string, the codesign step is skipped completely. We needed the last feature to enable building lldb on buildservers which do not have the right certificates installed. Reviewers: sas, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20623 llvm-svn: 270832
* Add support for arm64 compact unwind tables, used on darwin arm64Jason Molenda2016-05-251-0/+149
| | | | | | | | | | | | | | systems (ios, tvos, watchos). It's a simple format to use now that I have i386/x86_64 supported already. The unwind instructions are only valid at call sites -- that is, when lldb is unwinding a frame in the middle of the stack. It cannot be used for the currently executing frame; it has no information about prologues/epilogues/etc. <rdar://problem/12062336> llvm-svn: 270658
* Check that __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is definedJason Molenda2016-05-191-1/+1
| | | | | | | before comparing the value of it. <rdar://problem/26333564> llvm-svn: 270015
* Fix an issue where debugserver would not properly vend OS version ↵Enrico Granata2016-05-181-7/+5
| | | | | | | | | | | information on iOS devices The __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED macro is only defined on OS X, so the check as written compiled the code out for iOS The right thing to do is compile the code out for older OSX versions, but leave iOS alone rdar://26333564 llvm-svn: 270004
* Don't crash when a process' task port goes bad.Greg Clayton2016-05-121-1/+0
| | | | | | <rdar://problem/26256049> llvm-svn: 269373
* debugserver; fix -Wunused-local-typedef, -Wunused-variable warningsSaleem Abdulrasool2016-05-061-7/+0
| | | | | | | Remove the typedef and local structure which was unused. Fixes last of the new clang warnings in the debugserver build. NFC. llvm-svn: 268759
* debugserver: fix a couple of -Wmissing-field-initializers warningsSaleem Abdulrasool2016-05-061-1/+3
| | | | | | | Explicitly provide an initializer for the std::vector in the constructed type. Addresses -Wmissing-field-initializers warnings from clang. NFC. llvm-svn: 268758
* debugserver: fix some -Wpessimizing-move warningsSaleem Abdulrasool2016-05-061-3/+3
| | | | | | | Remove the unnecessary use of std::move to permit the compiler to perform NVRO instead. Fixes more warnings from clang. NFC. llvm-svn: 268757
* debugserver: fix a few -Wcovered-swift-default warningsSaleem Abdulrasool2016-05-062-2/+0
| | | | | | | | Remove a couple of `default` cases from switches which are covered. This is beneficial since it would allow the compiler to indicate when a new enum value is added and the switch is not updated. Fixes some warnings from clang. NFC. llvm-svn: 268756
* debugserver: fix some -Wformat-pedantic warningsSaleem Abdulrasool2016-05-061-16/+7
| | | | | | | Perform explicit casts for the log message to address some `-Wformat-pedantic` warnings from clang. NFC. llvm-svn: 268755
* debugserver should fflush its log stream in FileLogCallback, now it does.Greg Clayton2016-05-021-2/+3
| | | | | | <rdar://problem/24728287> llvm-svn: 268325
* Don't disable stdin buffering on WindowsAdrian McCarthy2016-04-141-6/+5
| | | | | | | | Disabling buffering exposes a bug in the MS VS 2015 CRT implementation of fgets, where you sometimes have to hit Enter twice, depending on if the input had an odd or even number of characters. This was hidden until a few days ago by the Python initialization which was re-enabling buffering on the streams. A few days ago, Enrico make the Python initialization on-demand, which exposed this problem. llvm-svn: 266384
* [Driver] Fix a segfault in signal handlersPavel Labath2016-04-111-2/+6
| | | | | | | | | | | | | | | Summary: If we recieve a SIGCONT or SIGTSTP, while the driver is shutting down (which, sometimes, we do, for reasons which are not completely clear to me), we would crash to due a null pointer dereference. Guard against this situation. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18965 llvm-svn: 265958
* -thread-info in lldbmi does not conform to protocol. Should end with current ↵Chuck Ries2016-04-082-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thread id -thread-info in lldbmi does not conform to protocol. Should end with current thread id as described here: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Thread-Commands.html#GDB_002fMI-Thread-Commands When printing all threads, the current thread id should be printed afterwards. Example: -thread-info ^done,threads=[ {id="2",target-id="Thread 0xb7e14b90 (LWP 21257)", frame={level="0",addr="0xffffe410",func="__kernel_vsyscall", args=[]},state="running"}, {id="1",target-id="Thread 0xb7e156b0 (LWP 21254)", frame={level="0",addr="0x0804891f",func="foo", args=[{name="i",value="10"}], file="/tmp/a.c",fullname="/tmp/a.c",line="158"}, state="running"}], current-thread-id="1" (gdb) Patch from jacdavis@microsoft.com Reviewers: zturner, chuckr Differential Revision: http://reviews.llvm.org/differential/revision/edit/18880/ llvm-svn: 265858
* 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
OpenPOWER on IntegriCloud