summaryrefslogtreecommitdiffstats
path: root/lldb/tools/debugserver/source/MacOSX/MachProcess.mm
Commit message (Collapse)AuthorAgeFilesLines
* Save more descriptive error msg from FBS/BKS, relay it up to lldb.Jason Molenda2020-01-081-20/+26
| | | | | | | | | | | | | | | | | | | When lldb requests an app launch through FrontBoard/BackBoard, we get back an NSError object if there was a problem with an integer error code and a descriptive text string. debugserver would log the descriptive text string to the console, but it would only save the error code value, ask for the much-less-specific name of that error code, and send that very generic error word back to lldb. This patch saves the longer description of the failure when available, and sends that to lldb. If unavailable, it falls back to sending up the generic description of the error code as it was doing before. This only impacts the iOS on-device debugserver. <rdar://problem/49953304>
* [lldb][NFC] Use static_cast instead of reinterpret_cast where possibleRaphael Isemann2020-01-071-25/+26
| | | | | | | | | | | | | | Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`. Reviewers: shafik, JDevlieghere, labath Reviewed By: labath Subscribers: arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D72161
* Upstream macCatalyst support in debugserver and the macOS dynamic loaderAdrian Prantl2019-09-041-9/+15
| | | | | | | | | | | plugin. Unfortunately the test is currently XFAILed because of missing changes to the clang driver. Differential Revision: https://reviews.llvm.org/D67124 llvm-svn: 370931
* Upstream a few small Apple changes to debugserver - arm64_32, CatalystJason Molenda2019-08-071-22/+93
| | | | | | | | | Adrian's changes to support Catalyst processes and my changes to support debugserver running on an arm64_32 device (Apple Watch Series 4, which uses an IPL32 model on arm64 cpus). llvm-svn: 368118
* Change the logging on ptrace(PT_KILL) in MachProcess::Kill to logJason Molenda2019-03-201-3/+5
| | | | | | | | if LOG_PROCESS is enabled or if there was an error making that call. <rdar://problem/49036508> llvm-svn: 356626
* One more fix while I'm looking at this - remove the Jason Molenda2019-02-181-7/+1
| | | | | | | | | unused IsSBProcess method, and have IsFBSProcess return false if we don't have API that we can use to make that determination, so we'll try other API if we can. llvm-svn: 354289
* Ah, misunderstood Jonas' feedback - fix this so we'llJason Molenda2019-02-181-1/+2
| | | | | | | do the right thing when both API are available. We want to try both of them if the first one fails. llvm-svn: 354288
* Clean up an unused variable warning when building this forJason Molenda2019-02-181-0/+4
| | | | | | mac native. llvm-svn: 354287
* Add some unconditional logging on the failure points when attachingJason Molenda2019-02-151-32/+58
| | | | | | | | | | | | | | to a process so we'll always get messages in the console logs. Also make the "is frontboard process" / "is backboard process" determination lazy, specifically take it out of the MachProcess::AttachForDebug codepath when we are attaching to a process, to simplify attaching. <rdar://problem/47982516> <rdar://problem/48060134> llvm-svn: 354181
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Simplify Boolean expressionsJonas Devlieghere2018-12-151-6/+6
| | | | | | | | | | | This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
* Re-instate a bit of code that was commented out in r188246 whichJason Molenda2018-09-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | reads an ObjectFileMachO's string table in one chunk. Originally this was commented out because binaries in the system's shared cache all share a mega-string table and so reading the entire mega-strtab for each binary was a performance problem. In the reinstated code, I add a check that the binary we're reading from memory is not in the shared cache (there isn't a constant in <mach-o/loader.h> for this bit yet; we hardcode the value in one other place in ObjectFileMachO alread). For binaries that we're reading out of memory that are NOT in the shared cache, reading the string table in one chunk is a big performance improvement. Also have debugserver send up the flags value for binaries in its response to the jGetLoadedDynamicLibrariesInfos request. NFC. <rdar://problem/33604496> llvm-svn: 341511
* Add support for PLATFORM_*SIMULATORFrederic Riss2018-06-151-0/+8
| | | | | | | | | | The toolchain in Xcode 10 uses a new LC_BUILD_VERSION entry to identify simulator binaries. Add support for reading those to debugserver. The exisitng test testing that code is currently failling when run with Xcode 10, no need for a new test. llvm-svn: 334784
* Typo fixes.Bruce Mitchener2018-05-291-2/+2
| | | | | | | | | | Reviewers: javed.absar Subscribers: ki.stfu, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D47421 llvm-svn: 333399
* [debugserver] Return 'ios' instead of 'iphoneos' for the ostype.Frederic Riss2018-04-251-2/+2
| | | | | | | | | | | | | When I merged the 2 codepaths that return an OS type, I hade checked that the places accepting 'iphoneos' would also accept 'ios', but then I got it backwards and return 'iphoneos'. We use this value to build triples, and there 'iphoneos' is invalid. This also makes the test slightly simpler. llvm-svn: 330877
* [debugserver] Fix LC_BUILD_VERSION load command handling.Frederic Riss2018-04-061-80/+73
| | | | | | | | | | | | | | | | | | | | | | Summary: In one of the 2 places the LC_BUILD_VERSION load command is handled, there is a bug preventing us from actually handling them (the address where to read the load command was not updated). This patch factors reading the deployment target load commands into a helper and adds testing for the 2 code paths calling the helper. The testing is a little bit complicated because the only times those load commands matter is when debugging a simulator process. I added a new decorator to check that a specific SDK is available. The actual testing was fairly easy once I knew how to run a simulated process. Reviewers: jasonmolenda, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D45298 llvm-svn: 329374
* Upstreaming avx512 register support in debugserver. These changesJason Molenda2018-03-061-0/+39
| | | | | | | | | | | | | | | | | | | were originally written by Chris Bieneman, they've undergone a number of changes since then. Also including the debugserver bridgeos support, another arm environment that runs Darwin akin to ios. These codepaths are activated when running in a bridgeos environment which we're not set up to test today. There's additional (small) lldb changes to handle bridgeos binaries that still need to be merged up. Tested on a darwin system with avx512 hardware and without. <rdar://problem/36424951> llvm-svn: 326756
* Fix the -Wunused-function warning properly (MachProcess.mm)Vedant Kumar2017-12-061-1/+1
| | | | | | | r319938 was not NFC, because it got the preprocessor guard wrong. Check WITH_FBS and WITH_BKS before defining SplitEventData. llvm-svn: 319943
* Fix an -Wunused-function warning, NFCVedant Kumar2017-12-061-20/+22
| | | | llvm-svn: 319938
* Fix misc -Wcast-qual warnings, NFCVedant Kumar2017-12-061-4/+6
| | | | llvm-svn: 319937
* Recognize another magic token sent in the LaunchInfo's EventData.Jim Ingham2017-11-171-29/+71
| | | | | | <rdar://problem/32505028> llvm-svn: 318496
* Rename Error -> Status.Zachary Turner2017-05-121-6/+7
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* fix format specifier warningsTim Hammerquist2017-03-071-12/+19
| | | | llvm-svn: 297228
* Removed an unneccesary #if now that debugserver-mini links Foundation.Sean Callanan2017-01-261-2/+0
| | | | llvm-svn: 293161
* Link debugserver against Foundation to get access to NSProcessInfo.Sean Callanan2017-01-251-0/+2
| | | | | | debugserver-mini can't use Foundation so disable that code there. llvm-svn: 293098
* Change the timeout in CallBoardSystemServiceOpenApplication to Jason Molenda2016-12-201-1/+1
| | | | | | | | 30 seconds to match the old springboard timeout; the launcher should time out before that and we will hopefully get back an informative error message instead of timing out ourselves. llvm-svn: 290163
* Increase timeout for Frontboard app launch request from 9 to 20 secondsJason Molenda2016-12-081-1/+1
| | | | | | to match other timeouts. llvm-svn: 289023
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-3431/+3356
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* [debugserver] Delete CFData.{h,cpp}, since they appear to be dead (NFCI)Vedant Kumar2016-08-091-1/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D23070 llvm-svn: 278142
* 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-071-0/+45
| | | | | | | | | | | | 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-071-157/+319
| | | | | | | | | | | | 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
* 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
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($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
* Upstreaming the apple internal changes that accumulated during theJason Molenda2015-10-231-251/+589
| | | | | | | | | | | | previous release. Most of the diffs are duplication in the xcode project file caused by adding a "debugserver-mini" target. Jim Ingham added support for a new SPI needed to request app launches on iOS. Greg Clayton added code to indicate the platform of the binary (macosx, ios, watchos, tvos) based on Mach-O load commands. Jason Molenda added code so debugserver will identify when it is running on a tvos/watchos device to lldb. llvm-svn: 251091
* Fix lldb build on older OSX versions after svn commit r244716Dawn Perchik2015-08-271-0/+2
| | | | | | | | | | | | | | Older OSX versions don't define NSOperatingSystemVersion, so building lldb gets: error: unknown type name 'NSOperatingSystemVersion' This patch fixes the build by having GetOSVersionNumbers return false if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101000, causing lldb to behave the same as it did before the commit. Reviewed by: jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12396 llvm-svn: 246138
* Have debugserver send the OS version string plusJason Molenda2015-08-121-0/+24
| | | | | | | | | | major, minor, and patchlevel in the qHostInfo reply. Document that qHostInfo may report major/minor/patch separately / in addition to the version: combination. <rdar://problem/22125465> llvm-svn: 244716
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-241-1/+1
| | | | | | | | | | | | | | | Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
* Don't water JSONGenerator objects down into ObjectSP's too early so that we ↵Greg Clayton2015-07-221-31/+31
| | | | | | can call member functions specific to dictionaries and arrays without calling GetAsDictionary() or GetAsArray() on them. llvm-svn: 242917
* Fix warnings.Bruce Mitchener2015-07-221-4/+5
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11404 llvm-svn: 242913
* Add a another packet to the gdb-remote protocol,Jason Molenda2015-07-101-0/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | jGetLoadedDynamicLibrariesInfos. This packet is similar to qXfer:libraries:read except that lldb supplies the number of solibs that should be reported about, and the start address for the list of them. At the initial process launch we'll read the full list of solibs linked by the process -- at this point we could be using qXfer:libraries:read -- but on subsequence solib-loaded notifications, we'll be fetching a smaller number of solibs, often only one or two. A typical Mac/iOS GUI app may have a couple hundred different solibs loaded - doing all of the loads via memory reads takes a couple of megabytes of traffic between lldb and debugserver. Having debugserver summarize the load addresses of all the solibs and sending it in JSON requires a couple of hundred kilobytes of traffic. It's a significant performance improvement when communicating over a slower channel. This patch leaves all of the logic for loading the libraries in DynamicLoaderMacOSXDYLD -- it only call over ot ProcesGDBRemote to get the JSON result. If the jGetLoadedDynamicLibrariesInfos packet is not implemented, the normal technique of using memory read packets to get all of the details from the target will be used. <rdar://problem/21007465> llvm-svn: 241964
* Fix debugserver warnings on MacOSX.Greg Clayton2015-03-091-45/+44
| | | | llvm-svn: 231692
* Clarify the launch style for debugserver to use.Jason Molenda2014-10-281-6/+2
| | | | | | <rdar://problem/18786645> llvm-svn: 220761
* Increase the gdb-remote packet timeout for the first packet we sendJason Molenda2014-07-241-0/+9
| | | | | | | | | | | | | to the remote side (QStartNoAckMode) - it may take a little longer than normal to get a reply. In debugserver, hardcode the priority for several threads so they aren't de-prioritized when a user app is using system resources. Also, set the names of the threads. <rdar://problem/17509866> llvm-svn: 213828
* Fix typos.Bruce Mitchener2014-07-081-1/+1
| | | | llvm-svn: 212553
* Fix typos.Bruce Mitchener2014-07-011-3/+3
| | | | llvm-svn: 212132
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-131-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done. This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression. I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData. I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included. A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite. Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub. The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages. I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread. I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably. Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use. I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result. llvm-svn: 210874
* Allow for a task port to change when we exec. Greg Clayton2014-04-301-1/+25
| | | | llvm-svn: 207699
* Fixed an issue where we would try to interrupt a process while it is in the ↵Greg Clayton2014-04-241-2/+80
| | | | | | | | | | process of naturally stopping due to another reason (breakpoint, or step). Added a new MachProcess::Interrupt() which correctly tracks such cases and "does the right thing". <rdar://problem/16593556> llvm-svn: 207139
OpenPOWER on IntegriCloud