summaryrefslogtreecommitdiff
path: root/lldb/source/Host/linux
AgeCommit message (Collapse)Author
2025-05-07[LLDB] Add IsCoreDumping to ProcessInstanceInfo (#138580)Jacob Lalonde
This is the first useful patch in the series related to enabling `PTRACE_SEIZE` for processes Coredumping. In order to make the decision if we want to seize or attach, we need to expose that in processinfo. Which we acquire by reading it from `/proc/pid/status` Note that in status it is `CoreDumping` not `Coredumping`, so I kept with that, even if I prefer `Coredumping`
2025-04-29[lldb][AIX] get host info for AIX (#134354)Hemang Gadhavi
This PR is in reference to porting LLDB on AIX. Link to discussions on llvm discourse and github: 1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640 2. https://github.com/llvm/llvm-project/issues/101657 The complete changes for porting are present in this draft PR: https://github.com/llvm/llvm-project/pull/102601 - Added changes to make the common host support functions under `Host/posix` for unix-like system. Also, created the `unittests/Host/posix/` to test the hostInfo & support functions for unix-like system. - Added changes to get the host information for AIX. (GetProcessInfo()) (Information like : executable path, arch, process status etc.)
2025-04-25Fix connecting via abstract socket (#136466)Emre Kultursay
Commit 82ee31f and Commit 2e893124 added socket sharing, but only for unix domain sockets. That broke Android, which uses unix-abstract sockets.
2025-01-09[lldb] Move GetEnvironment function into common code (#122173)Brad Smith
2024-12-20[lldb][Linux] Moving generic APIs from HostInfoLinux to HostInfoPosix (#119694)Dhruv Srivastava
This change is related merging some of the APIs in HostInfoLinux into HostInfoPosix. Here is the reference PR comment: https://github.com/llvm/llvm-project/pull/117906#discussion_r1865427495, https://github.com/llvm/llvm-project/pull/117906#discussion_r1861616945
2024-11-28[lldb] Remove child_process_inherit from the socket classes (#117699)Pavel Labath
It's never set to true. Also, using inheritable FDs in a multithreaded process pretty much guarantees descriptor leaks. It's better to explicitly pass a specific FD to a specific subprocess, which we already mostly can do using the ProcessLaunchInfo FileActions.
2024-08-27[lldb] Turn lldb_private::Status into a value type. (#106163)Adrian Prantl
This patch removes all of the Set.* methods from Status. This cleanup is part of a series of patches that make it harder use the anti-pattern of keeping a long-lives Status object around and updating it while dropping any errors it contains on the floor. This patch is largely NFC, the more interesting next steps this enables is to: 1. remove Status.Clear() 2. assert that Status::operator=() never overwrites an error 3. remove Status::operator=() Note that step (2) will bring 90% of the benefits for users, and step (3) will dramatically clean up the error handling code in various places. In the end my goal is to convert all APIs that are of the form ` ResultTy DoFoo(Status& error) ` to ` llvm::Expected<ResultTy> DoFoo() ` How to read this patch? The interesting changes are in Status.h and Status.cpp, all other changes are mostly ` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git grep -l SetErrorString lldb/source) ` plus the occasional manual cleanup.
2024-07-25[lldb][Linux] Parse, but don't store "comm" from /proc/stat file (#100387)David Spickett
As reported in https://github.com/llvm/llvm-project/issues/89710, the %s code used for `comm` could and probably does, overflow the buffer. Likely we haven't seen it cause problems because the following data is overwritten right afterwards. Also scanf isn't a great choice here as this `comm` can include many characters that might trip up %s. We don't actually use `comm`, so parse but don't store it so we're not overflowing anything.
2024-06-14[lldb] Adds additional fields to ProcessInfo (#91544)Fred Grim
To implement SaveCore for elf binaries we need to populate some additional fields in the prpsinfo struct. Those fields are the nice value of the process whose core is to be taken as well as a boolean flag indicating whether or not that process is a zombie. This commit adds those as well as tests to ensure that the values are consistent with expectations
2024-04-18adds additional information to the ProcessInfo object for elf processes (#88995)Fred Grim
This adds some additional bits into a ProcessInfo structure that will be of use in filling structs in an elf core file. This is a demand for implementing process save-core
2023-12-22[lldb] Fix two deprecation warningsNico Weber
No behavior change.
2023-05-03[lldb] Remove distribution_id from ArchSpecAlex Langford
The qHostInfo packet in the gdb-remote communication protocol specifies that distribution_id can be set, so lldb handles that. But we store that in the ArchSpec representing the "Host" platform (whatever platform the debug server is running on). This field is otherwise unused in ArchSpec, so it would be a lot easier if we stored that information at the gdb-remote communication layer. Sidenote: The distribution_id field is currently unused but I did not want to remove it in case some folks found it useful (e.g. in downstream forks). Differential Revision: https://reviews.llvm.org/D149697
2023-01-07[lldb] Use std::optional instead of llvm::Optional (NFC)Kazu Hirata
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2023-01-07[lldb] Add #include <optional> (NFC)Kazu Hirata
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>. I'll post a separate patch to actually replace llvm::Optional with std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-04[lldb] Use std::nullopt instead of None (NFC)Kazu Hirata
This patch mechanically replaces None with std::nullopt where the compiler would warn if None were deprecated. The intent is to reduce the amount of manual work required in migrating from Optional to std::optional. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-08-20[clang][lldb][cmake] Use new `*_INSTALL_LIBDIR_BASENAME` CPP macroJohn Ericson
Use this instead of `*_LIBDIR_SUFFIX`, from which it is computed. This gets us ready for D130586, in which `*_LIBDIR_SUFFIX` is deprecated. Differential Revision: https://reviews.llvm.org/D132300
2022-08-18Revert "[cmake] Use `CMAKE_INSTALL_LIBDIR` too"John Ericson
This reverts commit f7a33090a91015836497c75f173775392ab0304d. Unfortunately this causes a number of failures that didn't show up in my local build.
2022-08-18[cmake] Use `CMAKE_INSTALL_LIBDIR` tooJohn Ericson
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it. Now we return this. `LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set `CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed entirely. I imagine this is too potentially-breaking to make LLVM 15. That's fine. I have a more minimal version of this in the disto (NixOS) patches for LLVM 15 (like previous versions). This more expansive version I will test harder after the release is cut. Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D130586
2022-08-13Use llvm::erase_value (NFC)Kazu Hirata
2022-07-28[NFC] Improve FileSpec internal APIs and usage in preparation for adding ↵Greg Clayton
caching of resolved/absolute. Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes. The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const. Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString: ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const; This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result. The patch: - Removes the non const GetDirectory() and GetFilename() get accessors - Adds set accessors to replace the above functions: SetDirectory() and SetFilename(). - Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites - Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently. Differential Revision: https://reviews.llvm.org/D130549
2022-07-23Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for ↵Nico Weber
adding caching of resolved/absolute." and follow-ups This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d. It broke the build on Windows, see comments on https://reviews.llvm.org/D130309 It also reverts these follow-ups: Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14. Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309." This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24. Revert "Cache the value for absolute path in FileSpec." This reverts commit dabe877248b85b34878e75d5510339325ee087d0.
2022-07-22Fix buildbot breakage after https://reviews.llvm.org/D130309.Greg Clayton
2022-07-22Fix buildbot breakage after https://reviews.llvm.org/D130309.Greg Clayton
2022-04-05[lldb] Update reinterpret_cast in linux/Host.cppJonas Devlieghere
Fixes error: reinterpret_cast from type ‘const uint8_t*’ {aka ‘const unsigned char*’} to type ‘char*’ casts away qualifiers
2022-04-01[lldb] Remove remaining calls to DataBufferLLVM::GetCharsJonas Devlieghere
Update the Linux and NetBSD Host libraries for 2165c36be445 which removed DataBufferLLVM::GetChars. These files are compiled conditionally based on the host platform.
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath
2021-10-26Modernize and simplify HostInfo::GetOSKernelDescriptionPavel Labath
Replace bool+by-ref argument with llvm::Optional, and move the common implementation into HostInfoPOSIX. Based on my (simple) experiment, the uname and the sysctl approach return the same value on MacOS, so there's no need for a mac-specific implementation of this functionality. Differential Revision: https://reviews.llvm.org/D112457
2021-10-22Host::GetOSBuildStringPavel Labath
2021-10-05[lldb] Remove some anonymous namespacesPavel Labath
.. and reduce the scope of others. They don't follow llvm coding standards (which say they should be used only when the same effect cannot be achieved with the static keyword), and they set a bad example.
2021-06-11[lldb] Fix leak in testVitaly Buka
Test leaks if we run tools/lldb/unittests/Host/HostTests without --gtest_filter Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D104091
2021-06-11[lldb] Move once_flags in HostInfoLinux so the internal state structRaphael Isemann
The HostInfoLinuxFields struct is supposed to be set up/torn down on Initialize/Terminate and should contain all the state of the plugin. `once_flags` are part of this state and should also be reset on `Terminate` so we can re-initialize these lazy values after the next `Initialize` call. This itself is NFC as the HostInfoLinux was broken before this patch and is still broken afterwards. D104091 will be the proper fix. Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D104093
2021-05-26[lldb][NFC] Use C++ versions of the deprecated C standard library headersRaphael Isemann
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent. Reviewed By: shafik Differential Revision: https://reviews.llvm.org/D103084
2021-04-13Reland "[lldb] [Process] Watch for fork/vfork notifications" for LinuxMichał Górny
Big thanks to Pavel Labath for figuring out my mistake. Differential Revision: https://reviews.llvm.org/D98822
2021-04-13Revert "[lldb] [Process] Watch for fork/vfork notifications" and associated ↵Pavel Labath
followups This commit has caused the following tests to be flaky: TestThreadSpecificBpPlusCondition.py TestExitDuringExpression.py The exact cause is not known yet, but since both tests deal with threads, my guess is it has something to do with the tracking of creation of new threads (which the commit touches upon). This reverts the following commits: d01bff8cbdc98fb8751f7bf10af19b47ae5c445d, ba62ebc48e8c424ce3a78ba01acda679d536dd47, e761b6b4c58d4f7ae1073d925d7cb321d68ee93a, a345419ee03095c8cdfbe1c2728467c4da8fa0a4.
2021-04-08[lldb] [Process] Watch for fork/vfork notificationsMichał Górny
Watch for fork(2)/vfork(2) (also fork/vfork-style clone(2) on Linux) notifications and explicitly detach the forked child process, and add initial tests for these cases. The code covers FreeBSD, Linux and NetBSD process plugins. There is no new user-visible functionality provided -- this change lays foundations over subsequent work on fork support. Differential Revision: https://reviews.llvm.org/D98822
2021-02-18[lldb] Fix shared library directory computation on windowsPavel Labath
Our code for locating the shared library directory works via dladdr (or the windows equivalent) to locate the path of an address known to reside in liblldb. This works great for C++ programs, but there's a catch. When (lib)lldb is used from python (like in our test suite), this dladdr call will return a path to the _lldb.so (or such) file in the python directory. To compensate for this, we have code which attempts to resolve this symlink, to ensure we get the canonical location. However, here's the second catch. On windows, this file is not a symlink (but a copy), so this logic fails. Since most of our other paths are derived from the liblldb location, all of these paths will be wrong, when running the test suite. One effect of this was the failure to find lldb-server in D96202. To fix this issue, I add some windows-specific code to locate the liblldb directory. Since it cannot rely on symlinks, it works by manually walking the directory tree -- essentially doing the opposite of what we do when computing the python directory. To avoid python leaking back into the host code, I implement this with the help of a callback which can be passed to HostInfo::Initialize in order to assist with the directory location. The callback lives inside the python plugin. I also strenghten the existing path test to ensure the returned path is the right one. Differential Revision: https://reviews.llvm.org/D96779
2020-09-02[lldb/Host] Add missing proc statesJordan Rupprecht
The /proc/<pid>/status parsing is missing a few cases: - Idle - Parked - Dead If we encounter an unknown proc state, this leads to an msan warning. In reality, we only check that the state != Zombie, so it doesn't really matter that we handle all cases, but handle them anyway (current list: [1]). Also explicitly set it to unknown if we encounter an unknown state. There will still be an msan warning if the proc entry has no `State:` line, but that should not happen. Use a StringSwitch to make the handling of proc states a little more compact. [1] https://github.com/torvalds/linux/blob/master/fs/proc/array.c Reviewed By: labath Differential Revision: https://reviews.llvm.org/D86818
2020-03-13[lldb/Reproducers] Intercept the FindProcesses APIJonas Devlieghere
This patch extends the reproducers to intercept calls to FindProcesses. During capture it serializes the ProcessInstanceInfoList returned by the API. During replay, it returns the serialized data instead of querying the host. The motivation for this patch is supporting the process attach workflow during replay. Without this change it would incorrectly look for the inferior on the host during replay and failing if no matching process was found. Differential revision: https://reviews.llvm.org/D75877
2020-03-12[lldb/Utility] Replace ProcessInstanceInfoList with std::vector. (NFCI)Jonas Devlieghere
Replace ProcessInstanceInfoList with std::vector<ProcessInstanceInfo> and update the call sites.
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-23[lldb][NFC] Delete empty file source/Host/linux/ProcessLauncherLinux.cppRaphael Isemann
This was renamed in 816ae4b0dfac9a2bd964e8c4dae6dd7183ceb92a but it seems the commit only emptied the file instead of deleting it.
2019-10-15[lldb-server/android] Show more processes by relaxing some checksWalter Erquinigo
By default `platform process list` only shows the processes of the current user that lldb-server can parse. There are several problems: - apk programs don't have an executable file. They instead use a package name as identifier. We should show them instead. - each apk also runs under a different user. That's how android works - because of the user permission, some files like /proc/<pid>/{environ,exe} can't be read. This results in a very small process list. This is a local run on my machine ``` (lldb) platform process list 2 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 23291 3177 aarch64-unknown-linux-android sh 23301 23291 aarch64-unknown-linux-android lldb-server ``` However, I have 700 processes running at this time. By implementing a few fallbacks for android, I've expanded this list to 202, filtering out kernel processes, which would presumably appear in this list if the device was rooted. ``` (lldb) platform process list 202 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ ... 12647 3208 aarch64-unknown-linux-android sh 12649 12647 aarch64-unknown-linux-android lldb-server 12653 982 com.samsung.faceservice 13185 982 com.samsung.vvm 15899 982 com.samsung.android.spay 16220 982 com.sec.spp.push 17126 982 com.sec.spp.push:RemoteDlcProcess 19772 983 com.android.chrome 20209 982 com.samsung.cmh:CMH 20380 982 com.google.android.inputmethod.latin 20879 982 com.samsung.android.oneconnect:Receiver 21212 983 com.tencent.mm 24459 1 aarch64-unknown-linux-android wpa_supplicant 25974 982 com.samsung.android.contacts 26293 982 com.samsung.android.messaging 28714 982 com.samsung.android.dialer 31605 982 com.samsung.android.MtpApplication 32256 982 com.bezobidny ``` Something to notice is that the architecture is unkonwn for all apks. And that's fine, because run-as would be required to gather this information and that would make this entire functionality massively slow. There are still several improvements to make here, like displaying actual user names, which I'll try to do in a following diff. Note: Regarding overall apk debugging support from lldb. I'm planning on having lldb spawn lldb-server by itself with the correct user, so that everything works well. The initial lldb-server used for connecting to the remote platform can be reused for such purpose. Furthermore, eventually lldb could also launch that initial lldb-server on its own. Differential Revision: D68289 llvm-svn: 374853
2019-10-14Revert "fix"Walter Erquinigo
This reverts commit d8af64c9a0228301f6fd0e1c841e4abe0b6f4801. llvm-svn: 374852
2019-10-14fixWalter Erquinigo
llvm-svn: 374846
2019-10-08Revert "[lldb-server/android] Show more processes and package name when ↵Pavel Labath
necessary" This reverts r373758 because it causes several to test to be flaky (= failing ~90% of the time) on linux. llvm-svn: 374030
2019-10-04[lldb-server/android] Show more processes and package name when necessaryWalter Erquinigo
Summary: By default `platform process list` only shows the processes of the current user that lldb-server can parse. There are several problems: - apk programs don't have an executable file. They instead use a package name as identifier. - each apk also runs under a different user. That's how android works - because of the user permission, some files like /proc/<pid>/{environ,exe} can't be read. This results in a very small process list. This is a local run on my machine ``` (lldb) platform process list 2 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ 23291 3177 aarch64-unknown-linux-android sh 23301 23291 aarch64-unknown-linux-android lldb-server ``` However, I have 700 processes running at this time. By implementing a few fallbacks for android, I've expanded this list to 202, filtering out kernel processes, which would presumably appear in this list if the device was rooted. ``` (lldb) platform process list 202 matching processes were found on "remote-android" PID PARENT USER TRIPLE NAME ====== ====== ========== ======================== ============================ ... 12647 3208 aarch64-unknown-linux-android sh 12649 12647 aarch64-unknown-linux-android lldb-server 12653 982 com.samsung.faceservice 13185 982 com.samsung.vvm 15899 982 com.samsung.android.spay 16220 982 com.sec.spp.push 17126 982 com.sec.spp.push:RemoteDlcProcess 19772 983 com.android.chrome 20209 982 com.samsung.cmh:CMH 20380 982 com.google.android.inputmethod.latin 20879 982 com.samsung.android.oneconnect:Receiver 21212 983 com.tencent.mm 24459 1 aarch64-unknown-linux-android wpa_supplicant 25974 982 com.samsung.android.contacts 26293 982 com.samsung.android.messaging 28714 982 com.samsung.android.dialer 31605 982 com.samsung.android.MtpApplication 32256 982 com.bezobidny ``` Something to notice is that the architecture is unkonwn for all apks. And that's fine, because run-as would be required to gather this information and that would make this entire functionality massively slow. There are still several improvements to make here, like displaying actual user names, which I'll try to do in a following diff. Note: Regarding overall apk debugging support from lldb. I'm planning on having lldb spawn lldb-server by itself with the correct user, so that everything works well. The initial lldb-server used for connecting to the remote platform can be reused for such purpose. Furthermore, eventually lldb could also launch that initial lldb-server on its own. Reviewers: clayborg, aadsm, labath, xiaobai Subscribers: srhines, krytarowski, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68289 llvm-svn: 373758
2019-07-24[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-05-23[lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine
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
2019-03-05[lldb] Fix linux host build after r355342Alexander Kornienko
llvm-svn: 355392