summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Platform
Commit message (Collapse)AuthorAgeFilesLines
* [NFC] Fixes -Wrange-loop-analysis warningsMark de Wever2020-01-011-1/+1
| | | | | | This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall. Differential Revision: https://reviews.llvm.org/D71857
* [lldb/Host] Use cmakedefine01 for LLDB_ENABLE_POSIXJonas Devlieghere2019-12-134-8/+8
| | | | | Rename LLDB_DISABLE_POSIX to LLDB_ENABLE_POSIX and use cmakedefine01 for consistency.
* [Target] Remove Target::GetScratchClangASTContextAlex Langford2019-12-121-2/+8
| | | | | | | Target doesn't really need to know about ClangASTContext more than any other TypeSystem. We can create a method ClangASTContext::GetScratch for anything who needs a ClangASTContext specifically instead of just a generic TypeSystem.
* [lldb] Remove FileSpec(FileSpec*) constructorPavel Labath2019-12-043-11/+11
| | | | | This constructor was the cause of some pretty weird behavior. Remove it, and update all code to properly dereference the argument instead.
* [lldb] s/FileSpec::Equal/FileSpec::MatchPavel Labath2019-12-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The FileSpec class is often used as a sort of a pattern -- one specifies a bare file name to search, and we check if in matches the full file name of an existing module (for example). These comparisons used FileSpec::Equal, which had some support for it (via the full=false argument), but it was not a good fit for this job. For one, it did a symmetric comparison, which makes sense for a function called "equal", but not for typical searches (when searching for "/foo/bar.so", we don't want to find a module whose name is just "bar.so"). This resulted in patterns like: if (FileSpec::Equal(pattern, file, pattern.GetDirectory())) which would request a "full" match only if the pattern really contained a directory. This worked, but the intended behavior was very unobvious. On top of that, a lot of the code wanted to handle the case of an "empty" pattern, and treat it as matching everything. This resulted in conditions like: if (pattern && !FileSpec::Equal(pattern, file, pattern.GetDirectory()) which are nearly impossible to decipher. This patch introduces a FileSpec::Match function, which does exactly what most of FileSpec::Equal callers want, an asymmetric match between a "pattern" FileSpec and a an actual FileSpec. Empty paterns match everything, filename-only patterns match only the filename component. I've tried to update all callers of FileSpec::Equal to use a simpler interface. Those that hardcoded full=true have been changed to use operator==. Those passing full=pattern.GetDirectory() have been changed to use FileSpec::Match. There was also a handful of places which hardcoded full=false. I've changed these to use FileSpec::Match too. This is a slight change in semantics, but it does not look like that was ever intended, and it was more likely a result of a misunderstanding of the "proper" way to use FileSpec::Equal. [In an ideal world a "FileSpec" and a "FileSpec pattern" would be two different types, but given how widespread FileSpec is, it is unlikely we'll get there in one go. This at least provides a good starting point by centralizing all matching behavior.] Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70851
* [lldb] Avoid snprintf in PlatformRemoteDarwinDevicePavel Labath2019-11-261-19/+14
| | | | This quashes a -Wformat-truncation warning.
* [LLDB] Cleanup the DataEncoder utility. (NFC)Jonas Devlieghere2019-11-131-1/+1
| | | | | This commit removes unused methods from the DataEncoder class and cleans up the API by making all the internal methods private.
* Modernize the rest of the Find.* API (NFC)Adrian Prantl2019-10-171-3/+3
| | | | | | | | | | | | This patch removes the size_t return value and the append parameter from the remainder of the Find.* functions in LLDB's internal API. As in the previous patches, this is motivated by the fact that these parameters aren't really used, and in the case of the append parameter were frequently implemented incorrectly. Differential Revision: https://reviews.llvm.org/D69119 llvm-svn: 375160
* Add arm64_32 support to lldb, an ILP32 codegen Jason Molenda2019-10-162-4/+19
| | | | | | | | | | that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
* uint32_t options -> File::OpenOptions optionsLawrence D'Anna2019-10-143-3/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch re-types everywhere that passes a File::OpenOptions as a uint32_t so it actually uses File::OpenOptions. It also converts some OpenOptions related functions that fail by returning 0 or NULL into llvm::Expected split off from https://reviews.llvm.org/D68737 Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68853 llvm-svn: 374817
* Add -fgnuc-version to ClangModuleCompilationOptions on Darwin.Adrian Prantl2019-10-111-1/+2
| | | | | | | | This adapts LLDB for https://reviews.llvm.org/D68055. Darwin's libC headers expect the GNUC macro to be set. llvm-svn: 374585
* [lldb] [cmake] Support linking against clang-cpp dylibMichal Gorny2019-10-041-1/+2
| | | | | | | | | Link against clang-cpp dylib rather than split libs when CLANG_LINK_CLANG_DYLIB is enabled. Differential Revision: https://reviews.llvm.org/D68456 llvm-svn: 373734
* factor out an abstract base class for FileLawrence D'Anna2019-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch factors out File as an abstract base class and moves most of its actual functionality into a subclass called NativeFile. In the next patch, I'm going to be adding subclasses of File that don't necessarily have any connection to actual OS files, so they will not inherit from NativeFile. This patch was split out as a prerequisite for https://reviews.llvm.org/D68188 Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D68317 llvm-svn: 373564
* Convert FileSystem::Open() to return Expected<FileUP>Lawrence D'Anna2019-09-261-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch converts FileSystem::Open from this prototype: Status Open(File &File, const FileSpec &file_spec, ...); to this one: llvm::Expected<std::unique_ptr<File>> Open(const FileSpec &file_spec, ...); This is beneficial on its own, as llvm::Expected is a more modern and recommended error type than Status. It is also a necessary step towards https://reviews.llvm.org/D67891, and further developments for lldb_private::File. Reviewers: JDevlieghere, jasonmolenda, labath Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D67996 llvm-svn: 373003
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-242-22/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* File::SetDescriptor() should require optionsJonas Devlieghere2019-09-231-3/+8
| | | | | | | | | | | | | | | | | | | | | | lvm_private::File::GetStream() can fail if m_options == 0 It's not clear from the header a File created with a descriptor will be not be usable by many parts of LLDB unless SetOptions is also called, but it is. This is because those parts of LLDB rely on GetStream() to use the file, and that in turn relies on calling fdopen on the descriptor. When calling fdopen, GetStream relies on m_options to determine the access mode. If m_options has never been set, GetStream() will fail. This patch adds options as a required argument to File::SetDescriptor and the corresponding constructor. Patch by: Lawrence D'Anna Differential revision: https://reviews.llvm.org/D67792 llvm-svn: 372652
* [Utility] Replace `lldb_private::CleanUp` by `llvm::scope_exit`Jonas Devlieghere2019-09-101-19/+26
| | | | | | | | | This removes the CleanUp class and replaces its usages with llvm's ScopeExit, which has similar semantics. Differential revision: https://reviews.llvm.org/D67378 llvm-svn: 371474
* [Platform/Android] Read the adb server from an env variable if setNathan Lanza2019-08-271-1/+6
| | | | | | | | | | | | | | | Summary: The environment variable ANDROID_ADB_SERVER_PORT can be defined to have adbd litsen on a different port. Teach lldb how to understand this via simply checking the env var. Reviewers: xiaobai, clayborg Subscribers: srhines Differential Revision: https://reviews.llvm.org/D66689 llvm-svn: 370106
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-2/+2
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-021-101/+95
| | | | | | | | | | | | | | | | | | | | | Summary: This is the next step in avoiding funneling all SymbolFile calls through the SymbolVendor. Right now, it is just a convenience function, but it allows us to update all calls to SymbolVendor functions to access the SymbolFile directly. Once all call sites have been updated, we can remove the GetSymbolVendor member function. This patch just updates the calls to GetSymbolVendor, which were calling it just so they could fetch the underlying symbol file. Other calls will be done in follow-ups. Reviewers: JDevlieghere, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65435 llvm-svn: 367664
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-293-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-291-4/+3
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* Let tablegen generate property definitionsJonas Devlieghere2019-07-253-9/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
* [LLDB] Find debugserver in Command Line Tools as wellAntonio Afonso2019-07-251-50/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This might be an edge case in regular use but if you're shipping an lldb version with no debugserver lldb will try to use the System one. However, lldb only knows how to find the Xcode one and not the Command Line Tools one. This diff fixes that. We try to find debugserver with `PlatformDarwin::LocateExecutable("debugserver")`, we call `xcode-select -p` to get the path and then assume this path is of Xcode. The changes I did are: * Change `PlatformDarwin::LocateExecutable` to also add the Command Line Tools directory to the list of paths to search for debugserver. * Created a new function to find the Command Line Tools directory named `GetCommandLineToolsLibraryPath`. * Refactored the code that calls `xcode-select -p` into its own function `GetXcodeSelectPath()`. There were 2 identical pieces of code for this so I reduced it to one and used this function everywhere instead. * I also changed `PlatformDarwin::GetSDKDirectoryForModules` to use the `SDKs` directory that exists in the Command Line Tools installation. I'm not sure how to create tests for this. PlatformDarwinTest is really limited and I couldn't find how to mock Filesystem::Instance() so I could create a virtual file system. Reviewers: clayborg, JDevlieghere Reviewed By: clayborg, JDevlieghere Subscribers: jasonmolenda, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65171 llvm-svn: 367052
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-2415-267/+245
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Support Linux signal return trampolines in frame initializationJoseph Tremoulet2019-07-191-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Add __kernel_rt_sigreturn to the list of trap handlers for Linux (it's used as such on aarch64 at least), and __restore_rt as well (used on x86_64). Skip decrement-and-recompute for trap handlers in InitializeNonZerothFrame, as signal dispatch may point the child frame's return address to the start of the return trampoline. Parse the 'S' flag for signal handlers from eh_frame augmentation, and propagate it to the unwind plan. Reviewers: labath, jankratochvil, compnerd, jfb, jasonmolenda Reviewed By: jasonmolenda Subscribers: clayborg, MaskRay, wuzish, nemanjai, kbarton, jrtc27, atanasyan, jsji, javed.absar, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D63667 llvm-svn: 366580
* [FileSpecList] Add EmplaceBack method (NFC)Jonas Devlieghere2019-07-181-1/+1
| | | | | | | | Instead of having to write FileSpecList::Append(FileSpec(args)) you can now call FileSpecList::EmplaceBack(args), similar to std::vector<>::emplace_back. llvm-svn: 366489
* Refactor ObjectFile::GetSDKVersionRaphael Isemann2019-07-031-4/+4
| | | | | | | | | | | | | | | | Summary: This patch modernizes the GetSDKVersion API and hopefully prevents problems such as the ones discovered in D61218. Reviewers: aprantl, jasonmolenda, clayborg Reviewed By: aprantl, clayborg Subscribers: clayborg, labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61233 llvm-svn: 365090
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-238-49/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify ArchSpec::IsMIPS()Fangrui Song2019-05-161-8/+1
| | | | llvm-svn: 360865
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [C128] "Virtual functions should specify exactly one of `virtual`, `override`, or `final`", I've added override where a virtual function is overriden but the explicit `override` keyword was missing. Whenever both `virtual` and `override` were specified, I removed `virtual`. As C.128 puts it: > [...] writing more than one of these three is both redundant and > a potential source of errors. I anticipate a discussion about whether or not to add `override` to destructors but I went for it because of an example in [ISOCPP1000]. Let me repeat the comment for you here: Consider this code: ``` struct Base { virtual ~Base(){} }; struct SubClass : Base { ~SubClass() { std::cout << "It works!\n"; } }; int main() { std::unique_ptr<Base> ptr = std::make_unique<SubClass>(); } ``` If for some odd reason somebody removes the `virtual` keyword from the `Base` struct, the code will no longer print `It works!`. So adding `override` to destructors actively protects us from accidentally breaking our code at runtime. [C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final [ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555 Reviewers: teemperor, JDevlieghere, davide, shafik Reviewed By: teemperor Subscribers: kwk, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61440 llvm-svn: 359868
* Fix a stack-smasher in PlatformMacOSX::GetSDKDirectory()Adrian Prantl2019-04-291-1/+1
| | | | | | | | | GetSDKVersion expects the number of version fields not their byte size and will happily overwrite later contents of the stack. Differential Revision: https://reviews.llvm.org/D61218 llvm-svn: 359471
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-261-1/+1
| | | | | | | | | | | | | | This is part two of the change started in r359330. This patch moves the ownership of the script interpreter from the command interpreter into the debugger. I would've preferred to remove the lazy initialization, however the fact that the scripting language is set after the debugger is created makes that tricky. So for now this does exactly the same thing as when it was under the command interpreter. The result is that this patch is fully NFC. Differential revision: https://reviews.llvm.org/D61211 llvm-svn: 359354
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
* Lock accesses to OptionValueFileSpecList objectsFrederic Riss2019-04-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Before a Debugger gets a Target, target settings are routed to a global set of settings. Even without this, some part of the LLDB which exist independently of the Debugger object (the Module cache, the Symbol vendors, ...) access directly the global default store for those settings. Of course, if you modify one of those global settings while they are being read, bad things happen. We see this quite a bit with FileSpecList settings. In particular, we see many cases where one debug session changes target.exec-search-paths while another session starts up and it crashes when one of those accesses invalid FileSpecs. This patch addresses the specific FileSpecList issue by adding locking to OptionValueFileSpecList and never returning by reference. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60468 llvm-svn: 359028
* One small tweak to LocateExecutableScriptingResources - IJason Molenda2019-04-231-2/+2
| | | | | | | | | was still stat'ing the possibly-dSYM FileSpec before I (more cheaply) checked the filepath for telltale dSYM components. <rdar://problem/50086007> llvm-svn: 358939
* Add a small check to PlatformDarwin::LoadScriptingResourceForModuleJason Molenda2019-04-231-3/+6
| | | | | | | | | | | | | | | | | which reads the python files in a dSYM bundle, to check that the SymbolFile is actually a dSYM bundle filepath; delay any fetching of the ScriptInterpreter until after we've done that check. When debugging a binary without a dSYM on darwin systems, the SymbolFile we fetch is actually the ObjectFile -- so we would do an unnecessary trip into Python land and stat around the filesystem looking for a python file to read in. There's no reason to do any of this unless the SymbolFile's file path includes the .dSYM bundle telltale path components. <rdar://problem/50065315> llvm-svn: 358938
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1039-206/+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-6/+1
| | | | | | | | | | | | | | | | setup Reviewers: zturner, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60440 llvm-svn: 358044
* Unify random timeouts throughout LLDB and make them configurable.Adrian Prantl2019-04-051-2/+2
| | | | | | | | | | | | | | | | | Since these timeouts guard against catastrophic error in debugserver, I also increased all of them to the maximum value among them. The motivation for this test was the observation that an asanified LLDB would often exhibit seemingly random test failures that could be traced back to debugserver packets getting out of sync. With this path applied I can no longer reproduce the one particular failure mode that I was investigating. rdar://problem/49441261 Differential Revision: https://reviews.llvm.org/D60340 llvm-svn: 357829
* [Platform] Remove Kalimba PlatformJonas Devlieghere2019-03-274-240/+0
| | | | | | | | | This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
* Add ability to import std module into expression parser to improve C++ debuggingRaphael Isemann2019-03-122-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging. What happens in this patch is that we inject a `@import std` into our expression source code. We also modify our internal Clang instance for parsing this expression to work with modules and debug info at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The C++ include paths for building are extracted from the debug info, which means that this currently only works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths are currently specified by LLDB. I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific C include paths for them). With this patch we can now: * Build a libc++ as a module and import it into the expression parser. * Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`. What doesn't work (yet): * Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work. * Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't call yet any function that returns a non-trivial type. * Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches. Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille Reviewed By: aprantl Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D58125 llvm-svn: 355939
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-045-3/+17
| | | | | | | | | | | | | | | | | | | | | 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
* Refactor user/group name resolving codePavel Labath2019-03-043-21/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Move Host/Symbols.cpp to Symbols/LocateSymbolFile.cppZachary Turner2019-02-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb-server] Add remote platform capabilities for WindowsAaron Smith2019-02-144-274/+14
| | | | | | | | | | | | | | | | | | Summary: Implement a few routines for Windows to support some basic process interaction and file system operations. Reviewers: zturner, llvm-commits, labath, jingham Reviewed By: labath Subscribers: emaste, jdoerfert, Hui, labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D56232 llvm-svn: 354010
* Replace 'ap' with 'up' suffix in variable names. (NFC)Jonas Devlieghere2019-02-131-4/+4
| | | | | | | | | | | | | | | | | The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix. In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well. I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional. llvm-svn: 353912
* Extract common PlatformPOSIX/Windows code into a separate classPavel Labath2019-02-124-359/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The two classes contained a lot of duplicated code, but there wasn't a good place to factor it to. It couldn't be the base Platform class, since we also have platforms which are only remote (such as PlatformGDBRemoteServer), and so it did not make sense for those to have an m_remote_platform member. This patch creates a new class, RemoteAwarePlatform, which can serve as a base class for platforms which can both serve as a host, and forward actions to a remote system. It is motivated partly by D56232 (which was about to add a bunch of additional duplicated methods), and partly by my own need to modify a function which happens to be implemented in both places identically. The patch moves the methods which are trivially identical in the two classes into the common base class, there were one or two more methods which could probably be merged into one, but this wasn't completely trivial, so I did not attempt to do that now. Reviewers: jingham, zturner, clayborg, asmith Subscribers: emaste, mgorny, Hui, lldb-commits Differential Revision: https://reviews.llvm.org/D58052 llvm-svn: 353812
* Use std::make_shared in LLDB (NFC)Jonas Devlieghere2019-02-112-5/+8
| | | | | | | | | | | Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
* Fixes for the ProcessLaunchInfo movePavel Labath2019-02-041-1/+1
| | | | llvm-svn: 353049
OpenPOWER on IntegriCloud