summaryrefslogtreecommitdiffstats
path: root/lldb/source/Host
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix off-by-one error.Richard Trieu2019-05-311-1/+1
| | | | | | | The created string is one char too large, so it pulls the terminating NULL as the last character of the string. This later causes SocketTest.cpp to fail. llvm-svn: 362192
* Make ConnectionFileDescription work with all socketsAntonio Afonso2019-05-304-7/+42
| | | | | | | | | | | | | | | | | | | | | Summary: My main goal here is to make lldb-server work with Android Studio. This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection. To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket. Reviewers: labath, clayborg, xiaobai Reviewed By: labath Subscribers: mgorny, jfb, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62089 llvm-svn: 362173
* Fix IPv6 support on lldb-server platformAntonio Afonso2019-05-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a general fix for the ConnectionFileDescriptor class but my main motivation was to make lldb-server working with IPv6. The connect URI can use square brackets ([]) to wrap the interface part of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses this is a must since its ip can include colons and it will overlap with the port colon otherwise. The URIParser class parses the square brackets correctly but the ConnectionFileDescriptor doesn't generate them for IPv6 addresses making it impossible to connect to the gdb server when using this protocol. How to reproduce the issue: ``` $ lldb-server p --server --listen [::1]:8080 ... $ lldb (lldb) platform select remote-macosx (lldb) platform connect connect://[::1]:8080 (lldb) platform process -p <pid> error: unable to launch a GDB server on 'computer' ``` The server was actually launched we were just not able to connect to it. With this fix lldb will correctly connect. I fixed this by wrapping the ip portion with []. Reviewers: labath Reviewed By: labath Subscribers: xiaobai, mgorny, jfb, lldb-commits, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D61833 llvm-svn: 361898
* Revert "[lldb] followup fix for https://reviews.llvm.org/D62305"Jonas Devlieghere2019-05-241-4/+4
| | | | | | | | This fails on the Windows bot: cannot convert from 'initializer list' to 'lldb::thread_result_t' llvm-svn: 361583
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-241-1/+1
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* [lldb] followup fix for https://reviews.llvm.org/D62305Konrad Kleine2019-05-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixing this error on windows build bot: ``` E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type ``` see http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5050/steps/build/logs/stdio Reviewers: stella.stamenova, JDevlieghere Reviewed By: JDevlieghere Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62337 llvm-svn: 361565
* [HostNativeThreadBase] Undo nullptr changesJonas Devlieghere2019-05-231-4/+4
| | | | | | | The thread result type is an unsigned instead of a pointer on windows, so we shouldn't replace 0 with nullptr here. llvm-svn: 361528
* [lldb] fix cannot convert from 'nullptr' to 'lldb::thread_result_t'Konrad Kleine2019-05-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows `lldb::thread_result_t` resolves to `typedef unsigned thread_result_t;` and on other platforms it resolves to `typedef void *thread_result_t;`. Therefore one cannot use `nullptr` when returning from a function that returns `thread_result_t`. I've made this change because a windows build bot fails with these errors: ``` E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type ``` and ``` E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type ``` This is the failing build: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5035/steps/build/logs/stdio Reviewers: JDevlieghere, teemperor, jankratochvil, labath, clayborg, RKSimon, courbet, jhenderson Reviewed By: labath, clayborg Subscribers: labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62305 llvm-svn: 361503
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-2316-40/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Ack, added DWARFTypeUnit to the wrong target...Jim Ingham2019-05-231-1/+3
| | | | | | LLDB -> liblldbcore.a llvm-svn: 361447
* [EditLine] Rewrite GetHistoryFilePathJonas Devlieghere2019-05-221-13/+18
| | | | | | | | | | | | | | | | | | | | Rewrite the GetHistoryFilePath implementation without relying on FileSpec in the spirit of our discussion in D61994. It changes LLDBs behavior in two ways: 1. We now only use the -widehistory suffix when LLDB is built with wchar support, instead of as the fallback from when the ~/.lldb directory isn't writable. 2. When the ~/.lldb directory isn't writable, we don't write any history files at all. Previously we would write them to the user's home directory (with the incorrect wide suffix), polluting ~ with a different file for every IO handler. Differential revision: https://reviews.llvm.org/D62216 llvm-svn: 361412
* [FileSystem] Fix regression in FileSystem::ResolveJonas Devlieghere2019-05-211-8/+12
| | | | | | | | | | | | | | | | When I moved the resolve code from FileSpec to the FileSystem class, I introduced a regression. If you compare the two implementations, you'll notice that if the path doesn't exist, we should only reverse the effects of makeAbsolute, not the effects of tilde expansion. As a result, the logic to create the ~/.lldb directory broke, because we would resolve the path before creating it. Because the directory didn't exist yet, we'd call create_directories on the unresolved path, which failed. Differential revision: https://reviews.llvm.org/D62219 llvm-svn: 361321
* Fix LLDB warnings when compiling with Clang 8.0Alexandre Ganea2019-05-215-7/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D62021 llvm-svn: 361295
* Revert "Fix IPv6 support on lldb-server platform"Alex Langford2019-05-181-1/+1
| | | | | | | | | | | This reverts commit c28f81797084b8416ff5be4f9e79000a9741ca6a. This reverts commit 7e79b64642486f510f7872174eb831df68d65b84. Looks like there is more work to be done on this patch. I've spoken to the author and for the time being we will revert to keep the buildbots green. llvm-svn: 361086
* Fix IPv6 support on lldb-server platformAlex Langford2019-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a general fix for the ConnectionFileDescriptor class but my main motivation was to make lldb-server working with IPv6. The connect URI can use square brackets ([]) to wrap the interface part of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses this is a must since its ip can include colons and it will overlap with the port colon otherwise. The URIParser class parses the square brackets correctly but the ConnectionFileDescriptor doesn't generate them for IPv6 addresses making it impossible to connect to the gdb server when using this protocol. How to reproduce the issue: $ lldb-server p --server --listen [::1]:8080 ... $ lldb (lldb) platform select remote-macosx (lldb) platform connect connect://[::1]:8080 (lldb) platform process -p <pid> error: unable to launch a GDB server on 'computer' The server was actually launched we were just not able to connect to it. With this fix lldb will correctly connect. I fixed this by wrapping the ip portion with []. Differential Revision: https://reviews.llvm.org/D61833 Patch by António Afonso <antonio.afonso@gmail.com> llvm-svn: 361079
* [EditLine] Check string pointers before dereferencing them.Davide Italiano2019-05-171-2/+3
| | | | | | | | | Get*AtIndex() can return nullptr. This only happens in the swift REPL support, so it's hard to test upstream. <rdar://problem/50875178> llvm-svn: 361078
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-151-4/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* Mark private unimplemented functions as deletedJonas Devlieghere2019-05-151-2/+2
| | | | | | | Applies modernize-use-equals-delete to the LLDB code base and removes the now redundant comments. llvm-svn: 360751
* Fix file names in file headers. NFCFangrui Song2019-05-131-1/+1
| | | | llvm-svn: 360554
* [Host] Clean up dependencies of HostMacOSXObjCXXAlex Langford2019-05-071-4/+0
| | | | llvm-svn: 360178
* Editline: Fix an msan errorPavel Labath2019-04-291-3/+7
| | | | | | | | | | | | | | | | | | | | Summary: libedit implementation of el_get(EL_GETTC) had a bug, where it was consuming vararg arguments until reaching the first null pointer (and not just two, as documented). This was causing (at least) errors to be reported when running the tests under msan. The issue has since been fixed in libedit, but this adds patch adds a trivial workaround, so that we operate correctly with the libedit versions which are already out there. Reviewers: christos, krytarowski, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D61191 llvm-svn: 359449
* Hide stderr output from lldb-argdumperAdrian Prantl2019-04-242-9/+17
| | | | | | | | | | | | | Under very specific circumstances the default shell /bin/sh might print stuff to stderr before launching lldb-argdumper, which then confuses the JSON parser. This patch suppresses stderr output from lldb-argdumper to avoid this situation. rdar://problem/50149390 Differential Revision: https://reviews.llvm.org/D61101 llvm-svn: 359156
* Clear the output string passed to GetHostName()Aaron Smith2019-04-171-0/+2
| | | | | | | | LLVM's wchar to UTF8 conversion routine expects an empty string to store the output. GetHostName() on Windows is sometimes called with a non-empty string which triggers an assert. The simple fix is to clear the output string before the conversion. llvm-svn: 358550
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1025-174/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* [lldb-server] Introduce Socket::Initialize and Terminate to simply WSASocket ↵Aaron Smith2019-04-101-0/+27
| | | | | | | | | | | | | | | | setup Reviewers: zturner, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60440 llvm-svn: 358044
* Fix a stack buffer overflow found by ASAN.Adrian Prantl2019-04-081-5/+6
| | | | | | | | | | llvm::StringRef host_and_port is not guaranteed to be null-terminated. Generally, it is not safe at all to convert a StringRef into a char * by calling data() on it. <rdar://problem/49698580> llvm-svn: 357948
* [CMake] Move link dependencies where they are used.Jonas Devlieghere2019-03-291-1/+9
| | | | | | | | | The utility library shouldn't depend on curses, libedit or python. Move curses to core, libedit to host and python to the python plugin. Differential revision: https://reviews.llvm.org/D59970 llvm-svn: 357287
* [lldb] Add missing EINTR handlingMichal Gorny2019-03-219-15/+29
| | | | | | Differential Revision: https://reviews.llvm.org/D59606 llvm-svn: 356703
* Make sure FileSystem::Resolve preserves the path/file distinction.Adrian Prantl2019-03-131-1/+4
| | | | | | This should finally fix TestPaths.py. llvm-svn: 356057
* Fix invalid use of StringRef::data in Socket::DecodeHostAndPortPavel Labath2019-03-111-5/+3
| | | | | | | | | | | | the input StringRef is not guaranteed to be null-terminated, so using data to get the c string is wrong. Luckily, in two of the usages the target function already accepts a StringRef so we can just drop the data() call, and the third one is easily replaced by a stringref-aware function. Issue found by msan. llvm-svn: 355817
* Remove dependency edges from Host to Target/Core.Zachary Turner2019-03-081-1/+0
| | | | | | After recent changes, Host is now dependency-free. llvm-svn: 355730
* [ExpressionParser] Implement ComputeClangResourceDir for WindowsAlex Langford2019-03-072-37/+32
| | | | | | | | | | | | | | | | Summary: This function is useful for expression evaluation, especially when doing swift debugging on windows. Reviewers: aprantl, labath Reviewed By: labath Subscribers: teemperor, jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59072 llvm-svn: 355631
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-2/+2
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Resubmit "Don't include UnixSignals.h from Host."Zachary Turner2019-03-061-7/+0
| | | | | | | | This was reverted because it breaks the GreenDragon bot, but the reason for the breakage is lost, so I'm resubmitting this now so we can find out what the problem is. llvm-svn: 355528
* One more UserIDResolver fixPavel Labath2019-03-051-1/+1
| | | | | | | | | | | | | | | | | The intention in r355323 has been to implement a no-op resolver in the HostInfoBase class, which will then be shadowed a an implementation in the HostInfoPosix class. However, I add the shadowing declaration in HostInfoPosix.h, and instead had implemented the HostInfoBase function in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and a subsequent implementation of a no-op resolver in HostInfoWindows (r355329). Since now there is no point on having a no-op resolver in the base class, I just remove the base declaration altogether, and have HostInfoPosix implement the (newly-declared) HostInfoPosix version of that function. llvm-svn: 355398
* [lldb] Fix linux host build after r355342Alexander Kornienko2019-03-051-0/+1
| | | | llvm-svn: 355392
* [Host] Fix the build (and the modules build).Davide Italiano2019-03-051-0/+1
| | | | | | | -> Add a missing include to find the base class. -> Add a missing out-of-line declaration for a member function. llvm-svn: 355353
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-049-121/+24
| | | | | | | | | | | | | | | | | | | | | There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist. To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being. After this there is only 2 remaining references to Target from Host, which I'll address in a followup. Differential Revision: https://reviews.llvm.org/D58842 llvm-svn: 355342
* Fix Windows build after UserIDResolver patch.Zachary Turner2019-03-041-0/+20
| | | | | | | | | That patch added a function to HostInfo that returns an instance of UserIDResolver, but this function was unimplemented on Windows, leading to linker errors. For now, just return a dummy implementation that doesn't resolve user ids to get the build green. llvm-svn: 355329
* Refactor user/group name resolving codePavel Labath2019-03-041-31/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This creates an abstract base class called "UserIDResolver", which can be implemented to provide user/group ID resolution capabilities for various objects. Posix host implement a PosixUserIDResolver, which does that using posix apis (getpwuid and friends). PlatformGDBRemote forwards queries over the gdb-remote link, etc. ProcessInstanceInfo class is refactored to make use of this interface instead of taking a platform pointer as an argument. The base resolver class already implements caching and thread-safety, so implementations don't have to worry about that. The main motivating factor for this was to remove external dependencies from the ProcessInstanceInfo class (so it can be put next to ProcessLaunchInfo and friends), but it has other benefits too: - ability to test the user name caching code - ability to test ProcessInstanceInfo dumping code - consistent interface for user/group resolution between Platform and Host classes. Reviewers: zturner, clayborg, jingham Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58167 llvm-svn: 355323
* Delete commented-out code.Adrian Prantl2019-03-011-6/+0
| | | | llvm-svn: 355238
* Improve process launch comments for WindowsAdrian McCarthy2019-02-281-3/+7
| | | | | | | | | | | | | The existing comment about over-allocating the command line was incorrect. The contents of the command line may be changed, but it's not necessary to over allocate. The changes will be limited to the existing contents of the string (e.g., by replacing spaces with L'\0' to tokenize the command line). Also added a comment explaining a possible cause of failure to save the next programmer some time when they try to debug a 64-bit process from a 32-bit LLDB. llvm-svn: 355121
* Remove dependency from Host -> Core.Zachary Turner2019-02-271-1/+0
| | | | | | | I wasn't actually trying to eliminate this one, but looks like it happened as a side effect of moving Symbols out of Host. llvm-svn: 355037
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-273-1040/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Given that we have a target named Symbols, one wonders why a file named Symbols.cpp is not in this target. To be clear, the functions exposed from this file are really focused on *locating* a symbol file on a given host, which is where the ambiguity comes in. However, it makes more sense conceptually to be in the Symbols target. While some of the specific places to search for symbol files might change depending on the Host, this is not inherently true in the same way that, for example, "accessing the file system" or "starting threads" is fundamentally dependent on the Host. PDBs, for example, recently became a reality on non-Windows platforms, and it's theoretically possible that DSYMs could become a thing on non MacOSX platforms (maybe in a remote debugging scenario). Other types of symbol files, such as DWO, DWP, etc have never been tied to any Host platform anyway. After this patch, there is only one remaining dependency from Host to Target. Differential Revision: https://reviews.llvm.org/D58730 llvm-svn: 355032
* Revert "Don't include UnixSignals.h from Host."Davide Italiano2019-02-152-5/+11
| | | | | | It broke the modules green dragon buildbot. llvm-svn: 354177
* Don't include UnixSignals.h from Host.Zachary Turner2019-02-152-11/+5
| | | | | | | | | | | | | | | | | Host had a function to get the UnixSignals instance corresponding to the current host architecture. This means that Host had to include a file from Target. To break this dependency, just make this a static function directly in UnixSignals. We already have the function UnixSignals::Create(ArchSpec) anyway, so we just need to have UnixSignals::CreateForHost() which determines which value to pass for the ArchSpec. The goal here is to eventually break the Host->Target->Host circular dependency. Differential Revision: https://reviews.llvm.org/D57780 llvm-svn: 354168
* [lldb] [MainLoop] Add kevent() EINTR handlingMichal Gorny2019-02-151-2/+8
| | | | | | | | | | | | | Add missing EINTR handling for kevent() calls. If the call is interrupted, return from Poll() as if zero events were returned and let the polling resume on next iteration. This fixes test flakiness on NetBSD. Includes a test case suggested by Pavel Labath on D42206. Differential Revision: https://reviews.llvm.org/D58230 llvm-svn: 354122
* Sort files in source/Host/CMakeLists.txtPavel Labath2019-02-151-4/+4
| | | | llvm-svn: 354112
* [lldb] [MainLoop] Remove redundant termination clause (NFCI)Michal Gorny2019-02-141-3/+0
| | | | | | | | | | | | | Remove the redundant termination clause from within the loop. Since the check is done at the end of the loop, it's entirely redundant to the 'while' condition. If termination was requested, the latter will become false and the 'while' loop will terminate, resulting in the 'return' statement below the loop being executed (which is equivalent to the one used inside 'if'). Differential Revision: https://reviews.llvm.org/D58227 llvm-svn: 354050
* [lldb] [MainLoop] Report errno for failed kevent()Michal Gorny2019-02-141-1/+1
| | | | | | | | | | Modify the kevent() error reporting to use errno rather than returning the return value. At least on FreeBSD and NetBSD, kevent() always returns -1 in case of error, and the actual error is returned via errno. Differential Revision: https://reviews.llvm.org/D58229 llvm-svn: 354029
OpenPOWER on IntegriCloud