summaryrefslogtreecommitdiffstats
path: root/lldb/source/Host/common/MonitoringProcessLauncher.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Change LaunchThread interface to return an Expected for non-Apple-non-WindowsFangrui Song2019-07-081-2/+6
| | | | | | Fixes Linux build errors after D64163/r365226 llvm-svn: 365295
* Move FileAction, ProcessInfo and ProcessLaunchInfo from Target to HostPavel Labath2019-02-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: These classes describe the details of the process we are about to launch, and so they are naturally used by the launching code in the Host module. Previously they were present in Target because that is the most important (but by far not the only) user of the launching code. Since the launching code has other customers, must of which do not care about Targets, it makes sense to move these classes to the Host layer, next to the launching code. This move reduces the number of times that Target is included from host to 8 (it used to be 14). Reviewers: zturner, clayborg, jingham, davide, teemperor Subscribers: emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D56602 llvm-svn: 353047
* 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
* [FileSystem] Migrate MonitoringProcessLauncherJonas Devlieghere2018-12-031-10/+5
| | | | | | Use the FileSystem helpers instead of using the file system directly. llvm-svn: 348207
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-011-1/+1
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [FileSystem] Remove ResolveExecutableLocation() from FileSpecJonas Devlieghere2018-11-011-1/+2
| | | | | | | | | This patch removes the ResolveExecutableLocation method from FileSpec and updates its uses with calls to the FileSystem. Differential revision: https://reviews.llvm.org/D53834 llvm-svn: 345853
* Reapply "Remove Process references from the Host module"Pavel Labath2018-05-151-13/+3
| | | | | | This re-lands r332250/D46395, after fixing Mac build errors. llvm-svn: 332353
* Revert "Remove Process references from the Host module"Pavel Labath2018-05-141-3/+13
| | | | | | | | | | The first fix wasn't enough, there is still a missing ProcessInstanceInfo include in Host.mm. I won't be able to test a fix before leaving work, so I am reverting both commits. This reverts commit r332250 and the subsequent fix attempt. llvm-svn: 332261
* Remove Process references from the Host modulePavel Labath2018-05-141-13/+3
| | | | | | | | | | | | | | | | | | | | | The Process class was only being referenced because of the last-ditch effort in the process launchers to set a process death callback in case one isn't set already. Although launching a process for debugging is the most important kind of "launch" we are doing, it is by far not the only one, so assuming this particular callback is the one to be used is not a good idea (besides breaking layering). Instead of assuming a particular exit callback, I change the launcher code to require the callback to be set by the user (and fix up the two call sites which did not set the callback already). Reviewers: jingham, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D46395 llvm-svn: 332250
* Remove Platform references from the Host modulePavel Labath2018-01-191-26/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These were used by Host::LaunchProcess to "resolve" the executable it was about to launch. The only parts of Platform::ResolveExecutable, which seem to be relevant here are the FileSpec::ResolvePath and ResolveExecutableLocation calls. The rest (most) of that function deals with selecting an architecture out of a fat binary and making sure we are able to create a Module with that slice. These are reasonable actions when selecting a binary to debug, but not for a generic process launching framework (it's technically even wrong because we should be able to launch a binary with execute permissions only, but trying to parse such file will obviously fail). I remove the platform call by inlining the relevant FileSpec calls and ignoring the rest of the Platform::ResolveExecutable code. The architecture found by the slice-searching code is being ignored already anyway, as we use the one specified in the LaunchInfo, so the only effect of this should be a different error message in case the executable does not contain the requested architecture -- before we would get an error message from the Platform class, but now we will get an error from the actual posix_spawn syscall (this is only relevant on mac, as it's the only target supporting fat binaries). Launching targets for debugging should not be affected as here the executable is pre-resolved at the point when the Target is created. Reviewers: jingham, clayborg Subscribers: lldb-commits, emaste Differential Revision: https://reviews.llvm.org/D41902 llvm-svn: 322935
* Rename Error -> Status.Zachary Turner2017-05-121-2/+2
| | | | | | | | | | | | | | | 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
* Resubmit FileSystem changes.Zachary Turner2017-03-081-4/+9
| | | | | | | | | | This was originall reverted due to some test failures in ModuleCache and TestCompDirSymlink. These issues have all been resolved and the code now passes all tests. Differential Revision: https://reviews.llvm.org/D30698 llvm-svn: 297300
* Revert "Use LLVM for all stat-related functionality."Pavel Labath2017-03-071-5/+3
| | | | | | | | | | | | | | | this reverts r297116 because it breaks the unittests and TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat functionality is not a drop-in replacement for lldb's. The former is based on stat(2) (which does symlink resolution), while the latter is based on lstat(2) (which does not). This also reverts subsequent build fixes (r297128, r297120, 297117) and r297119 (Remove FileSpec dependency on FileSystem) which builds on top of this. llvm-svn: 297139
* Use LLVM for all stat-related functionality.Zachary Turner2017-03-071-3/+5
| | | | | | | | | | This deletes LLDB's FileType enumeration and replaces all users, and all calls to functions that check whether a file exists etc with corresponding calls to LLVM. Differential Revision: https://reviews.llvm.org/D30624 llvm-svn: 297116
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* 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
* [lldb] Fix typos in file headersAlexander Shaposhnikov2016-11-261-1/+1
| | | | | | | | | | | | | This diff fixes typos in file headers (incorrect file names). Test plan: Under llvm/tools/lldb/source: find ./* -type f | grep -e '\(cpp\|h\)$' | while read F; do B=$(basename $F); echo $F head -n 1 $F | grep -v $B | wc -l ; done Differential revision: https://reviews.llvm.org/D27115 llvm-svn: 287966
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-62/+54
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Generalize child process monitoring functionsPavel Labath2016-05-111-3/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the C-style "void *" baton of the child process monitoring functions with a more C++-like API taking a std::function. The motivation for this was that it was very difficult to handle the ownership of the object passed into the callback function -- each caller ended up implementing his own way of doing it, some doing it better than others. With the new API, one can just pass a smart pointer into the callback and all of the lifetime management will be handled automatically. This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate commit to reduce the scope of this change. Reviewers: clayborg, zturner, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20106 llvm-svn: 269205
* Fix broken build after signature change of ResolveExecutable.Zachary Turner2014-11-171-1/+3
| | | | llvm-svn: 222176
* Remove unused variable.Eric Christopher2014-10-151-2/+0
| | | | llvm-svn: 219751
* Create a process launcher abstraction.Zachary Turner2014-10-141-0/+102
This implements Host::LaunchProcess for windows, and in doing so does some minor refactor to move towards a more modular process launching design. The original motivation for this is that launching processes on windows needs some very windows specific code, which would live most appropriately in source/Host/windows somewhere. However, there is already some common code that all platforms use when launching a process before delegating to the platform specific stuff, which lives in source/Host/common/Host.cpp which would be nice to reuse without duplicating. This commonality has been abstracted into MonitoringProcessLauncher, a class which abstracts out the notion of launching a process using an arbitrary algorithm, and then monitoring it for state changes. The windows specific launching code lives in ProcessLauncherWindows, and the posix specific launching code lives in ProcessLauncherPosix. When launching a process MonitoringProcessLauncher is created, and then an appropriate delegate launcher is created and given to the MonitoringProcessLauncher. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D5781 llvm-svn: 219731
OpenPOWER on IntegriCloud