summaryrefslogtreecommitdiff
path: root/lldb/source/Host/linux/Host.cpp
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-01-09[lldb] Move GetEnvironment function into common code (#122173)Brad Smith
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-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-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-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
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
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-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
2019-03-04Move ProcessInfo from Host to Utility.Zachary Turner
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
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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
2018-11-12Re-land "Extract construction of DataBufferLLVM into FileSystem"Jonas Devlieghere
This fixes some UB in isLocal detected by the sanitized bot. llvm-svn: 346707
2018-11-12Revert "Extract construction of DataBufferLLVM into FileSystem"Davide Italiano
It broke the lldb sanitizer bots. llvm-svn: 346694
2018-11-11Remove header grouping comments.Jonas Devlieghere
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
2018-11-10Add missing includeJonas Devlieghere
llvm-svn: 346599
2018-11-10Extract construction of DataBufferLLVM into FileSystemJonas Devlieghere
This moves construction of data buffers into the FileSystem class. Like some of the previous refactorings we don't translate the path yet because the functionality hasn't been landed in LLVM yet. Differential revision: https://reviews.llvm.org/D54272 llvm-svn: 346598
2018-11-01[FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere
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
2018-06-13[FileSpec] Make style argument mandatory for SetFile. NFCJonas Devlieghere
Fix SetFile uses in hosts that I missed in r334663. llvm-svn: 334664
2018-04-30Reflow paragraphs in comments.Adrian Prantl
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-01-29Remove ObjectFile usage from HostLinux::GetProcessInfoPavel Labath
Summary: The ObjectFile class was used to determine the architecture of a running process by inspecting it's main executable. There were two issues with this: - it's in the wrong layer - the call can be very expensive (it can end up computing the crc of the whole file). Since the process is running on the host, ideally we would be able to just query the data straight from the OS like darwin does, but there doesn't seem to be a reasonable way to do that. So, this fixes the layering issue by using the llvm object library to inspect the file. Since we know the process is already running on the host, we just need to peek at a few bytes of the elf header to determine whether it's 32- or 64-bit (which should make this faster as well). Pretty much the same logic was implemented in NativeProcessProtocol::ResolveProcessArchitecture, so I delete this logic and replace calls with GetProcessInfo. Reviewers: eugene, krytarowski Subscribers: mgorny, hintonda, lldb-commits Differential Revision: https://reviews.llvm.org/D42488 llvm-svn: 323637
2018-01-10Add Utility/Environment class for handling... environmentsPavel Labath
Summary: There was some confusion in the code about how to represent process environment. Most of the code (ab)used the Args class for this purpose, but some of it used a more basic StringList class instead. In either case, the fact that the underlying abstraction did not provide primitive operations for the typical environment operations meant that even a simple operation like checking for an environment variable value was several lines of code. This patch adds a separate Environment class, which is essentialy a llvm::StringMap<std::string> in disguise. To standard StringMap functionality, it adds a couple of new functions, which are specific to the environment use case: - (most important) envp conversion for passing into execve() and likes. Instead of trying to maintain a constantly up-to-date envp view, it provides a function which creates a envp view on demand, with the expectation that this will be called as the very last thing before handing the value to the system function. - insert(StringRef KeyEqValue) - splits KeyEqValue into (key, value) pair and inserts it into the environment map. - compose(value_type KeyValue) - takes a map entry and converts in back into "KEY=VALUE" representation. With this interface most of the environment-manipulating code becomes one-liners. The only tricky part was maintaining compatibility in SBLaunchInfo, which expects that the environment entries are accessible by index and that the returned const char* is backed by the launch info object (random access into maps is hard and the map stores the entry in a deconstructed form, so we cannot just return a .c_str() value). To solve this, I have the SBLaunchInfo convert the environment into the "envp" form, and use it to answer the environment queries. Extra code is added to make sure the envp version is always in sync. (This also improves the layering situation as Args was in the Interpreter module whereas Environment is in Utility.) Reviewers: zturner, davide, jingham, clayborg Subscribers: emaste, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41359 llvm-svn: 322174
2017-07-18Clean up lldb-types.hPavel Labath
Summary: It defined a couple of types (condition_t) which we don't use anymore, as we have c++11 goodies now. I remove these definitions. Also it unnecessarily included a couple of headers which weren't necessary for it's operation. I remove these, and place the includes in the relevant files (usually .cpp, usually in Host code) which use them. This allows us to reduce namespace pollution in most of the lldb files which don't need the OS-specific definitions. Reviewers: zturner, jingham Subscribers: ki.stfu, lldb-commits Differential Revision: https://reviews.llvm.org/D35113 llvm-svn: 308304
2017-05-12Rename Error -> Status.Zachary Turner
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
2017-03-17Move GetAuxvData from Host to relevant process pluginsPavel Labath
Summary: GetAuxvData was causing dependencies from host to target and linux process modules. It also does not fit netbsd use case, as there we can only read the auxiliary vector with ptrace, which is better done in the process plugin, with the other ptrace calls. I resolve these issues by moving the freebsd and linux versions into the relevant process plugins. In case of linux, this required adding an interface in NativeProcessProtocol. The empty definitions on other platforms can simply be removed. To get the code compiling I had to add ProcessGdbRemote -> ProcessLinux dependency, which was not caught before because we depended on it transitively. Reviewers: zturner, emaste Subscribers: srhines, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D31031 llvm-svn: 298066
2017-03-15Remove some ProcFileReader occurencesPavel Labath
Summary: ProcFileReader is the cause of the dependency from Host to ProcessLinux module. Since it's interface is also obsolete (ReadIntoDataBuffer is trivially replaceable by llvm::MemoryBuffer functions and ProcessLineByLine is trivially implementable with StringRefs), instead of moving it around I'm planning to obliterate it. This is the first step, where I remove a couple of occurences in linux/Host.cpp, and modernize some code around that. I have introduced linux/Support.h, which holds two utility functions now, whose resposibility is to construct the appropriate proc file names -- the only useful feature of ProcFileReader. I add a couple of tests for these functions, and for Host::GetProcessInfo. It's worth noting that these are the first host-specific unit tests in lldb. Reviewers: zturner, eugene Subscribers: srhines, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D30942 llvm-svn: 297843
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner
llvm-svn: 296943
2017-03-03Move Log from Core -> Utility.Zachary Turner
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
2017-02-02Move classes from Core -> Utility.Zachary Turner
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
2016-09-19Fix more functions in Args to use StringRef.Zachary Turner
This patch also marks the const char* versions as =delete to prevent their use. This has the potential to cause build breakages on some platforms which I can't compile. I have tested on Windows, Linux, and OSX. Best practices for fixing broken callsites are outlined in Args.h in a comment above the deleted function declarations. Eventually we can remove these =delete declarations, but for now they are important to make sure that all implicit conversions from const char * are manually audited to make sure that they do not invoke a conversion from nullptr. llvm-svn: 281919
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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