summaryrefslogtreecommitdiffstats
path: root/lldb/unittests
Commit message (Collapse)AuthorAgeFilesLines
...
* Minidump: use ThreadList parsing code from llvm/ObjectPavel Labath2019-05-101-14/+14
| | | | llvm-svn: 360412
* [Reproducers] Fix reproducer unittestJonas Devlieghere2019-05-081-1/+3
| | | | | | | | | | | | | | | I think the recent change to flush the SB API recording uncovered a real issue on the Windows bot. Although I couldn't make much sense of the error message "unknown file: error: SEH exception with code 0x3221225477 thrown in the test body.", it prompted me to look at the test. In the unit test we were recording during replay, which is obviously not correct. I think we didn't see this issue before because we flushed once after the recording was done. This patch unsets the recording logic during the replay part of the test. Hopefully this fixed the Windows bot. llvm-svn: 360298
* Fix bug in ArchSpec::MergeFromGreg Clayton2019-05-081-0/+26
| | | | | | | | | | Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
* Fixup r360161Pavel Labath2019-05-072-3/+1
| | | | | | | | | Remove SymbolVendorMacOSX from the test, as this plugin is not available on non-mac platforms, and it does not seem to be necessary anyway. Declare inlined-functions.yaml as an input of the test in cmake. llvm-svn: 360169
* PostfixExpression: Use signed integers in IntegerNodePavel Labath2019-05-072-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is necessary to support parsing expressions like ".cfa -16 + ^", as that format is used in breakpad STACK CFI expressions. Since the PDB expressions use the same parser, this change will affect them too, but I don't believe that should be a problem in practice. If PDBs do contain the negative values, it's very likely that they are intended to be parsed the same way, and if they don't, then it doesn't matter. In case that we do ever need to handle this differently, we can always make the parser behavior customizable, or just use a different parser. To make sure that the integer size is big enough for everyone, I switch from using a (unsigned) 32-bit integer to a 64-bit (signed) one. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D61311 llvm-svn: 360166
* Added missing files from 360071.Greg Clayton2019-05-073-0/+1179
| | | | llvm-svn: 360161
* [CMake] Remove lldbPluginSymbolVendorMacOSX to fix CMake buildJonas Devlieghere2019-05-061-1/+0
| | | | | | This should fix check-lldb-unit on the bots. llvm-svn: 360079
* [CMake] Remove inlined-functions.yamlJonas Devlieghere2019-05-061-1/+0
| | | | llvm-svn: 360078
* Fix the cmake build by removing non-existant source fileReid Kleckner2019-05-061-1/+0
| | | | llvm-svn: 360076
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-0610-98/+61
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-034-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* PostfixExpression: Introduce InitialValueNodePavel Labath2019-04-301-0/+16
| | | | | | | | | | | | | | | | | | | | | | | Summary: This node represents can be used to refer to the initial value, which is sometimes pushed onto the DWARF stack as the "input" to the DWARF expression. The typical use case (and the reason why I'm introducing it) is that the "Canonical Frame Address" is passed this way to the DWARF expressions computing the values of registers during frame unwind. The nodes are converted into dwarf by keeping track of DWARF stack depth an any given point, and then copying the initial value from the bottom of the stack via the DW_OP_pick opcode. This could be made more efficient for simple expressions, but here I chose to start with the most general implementation possible. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai Differential Revision: https://reviews.llvm.org/D61183 llvm-svn: 359560
* Remove obsoleted NativePDB testsPavel Labath2019-04-291-26/+0
| | | | | | | | Their functionality overlaps with the newly introduced PostfixExpressionTests (r359288). Tests, which still exercise some pdb-related functionality (register name resolution) have been kept. llvm-svn: 359450
* DWARFExpression: Fix implementation of DW_OP_pickPavel Labath2019-04-292-0/+44
| | | | | | | | | | | | | | | | | | | | | | Summary: The DWARF spec states that the DWARF stack arguments are numbered from the top. Our implementation of DW_OP_pick was counting them from the bottom. This bug probably wasn't noticed because nobody (except my upcoming postfix-to-DWARF converter) uses DW_OP_pick, but I've cross-checked with gdb to confirm that counting from the top is the expected behavior. This patch fixes the implementation to match the spec and gdb behavior and adds a test. Reviewers: jasonmolenda, clayborg Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D61182 llvm-svn: 359436
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-261-0/+55
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new dwarf generator is pretty much a verbatim copy of the one in PDB. In order to write a pdb-independent test for it, I needed to write a dummy "symbol resolver", which (together with the fact that I'll need one more for breakpad-specific resolution logic) prompted me to create a more simple interface for algorithms which replace or "resolve" SymbolNodes. The resolving algorithms in NativePDB have been updated to make use of that too. I have removed a couple of NativePDB tests which weren't testing anything pdb-specific and where the tested functionality was covered by the new format-agnostic tests I have added. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D61056 llvm-svn: 359288
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-261-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [EditLineTests] Call setenv() before editline is initialized.Davide Italiano2019-04-241-3/+5
| | | | llvm-svn: 359124
* PostfixExpression: move parser out of NativePDB internalsPavel Labath2019-04-242-0/+98
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The postfix expressions in PDB and breakpad symbol files are similar enough that they can be parsed by the same parser. This patch generalizes the parser in the NativePDB plugin and moves it into the PostfixExpression file created in the previous commit (r358976). The generalization consists of treating any unrecognised token as a "symbol" node (previously these would only be created for tokens starting with "$", and other token would abort the parse). This is needed because breakpad symbols can also contain ".cfa" tokens, which refer to the frame's CFA. The cosmetic changes include: - using a factory function instead of a class for creating nodes (this is more generic as it allows the same BumpPtrAllocator to be used for other things too) - using dedicated function for parsing operator tokens instead of a DenseMap (more efficient as we don't need to create the DenseMap every time). Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny Differential Revision: https://reviews.llvm.org/D61003 llvm-svn: 359073
* Revert "[EditLineTest] Not always TERM is available, e.g. on some bots."Davide Italiano2019-04-231-13/+3
| | | | | | | This was a speculative fix trying to placate some bots, but it's ultimately just a bot configuration problem and not a code problem. llvm-svn: 359011
* [EditLineTest] Not always TERM is available, e.g. on some bots.Davide Italiano2019-04-221-3/+13
| | | | llvm-svn: 358918
* Minidump: yamlify module-related unit testsPavel Labath2019-04-216-134/+60
| | | | | | | | | | | | | The tests reading the untouched module list are now not using any lldb code (as module list loading lives in llvm now), so they can be removed. The "filtering" of the module list remains (and probably will remain) an lldb concept, so I keep those tests, but replace the checked-in binaries with their yaml equivalents. The binaries which are no longer referenced by any tests have been removed. llvm-svn: 358850
* Clear the output string passed to GetHostName()Aaron Smith2019-04-171-0/+6
| | | | | | | | LLVM's wchar to UTF8 conversion routine expects an empty string to store the output. GetHostName() on Windows is sometimes called with a non-empty string which triggers an assert. The simple fix is to clear the output string before the conversion. llvm-svn: 358550
* Breakpad: Match the new UUID algorithm in minidumpsPavel Labath2019-04-161-1/+1
| | | | | | | | | | | | | | | D59433 and D60501 changed the way UUIDs are computed from minidump files. This was done to synchronize the U(G)UID representation with the native tools of given platforms, but it created a mismatch between minidumps and breakpad files. This updates the breakpad algorithm to match the one found in minidumps, and also adds a couple of tests which should fail if these two ever get out of sync. Incidentally, this means that the module id in the breakpad files is almost identical to our notion of UUIDs, so the computation algorithm can be somewhat simplified. llvm-svn: 358500
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-103-14/+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
* Minidump: Use llvm parser for reading the ModuleList streamPavel Labath2019-04-101-24/+24
| | | | | | | | In this patch, I just remove the structure definitions for the ModuleList stream and the associated parsing code. The rest of the code is converted to work with the definitions in llvm. NFC. llvm-svn: 358070
* [lldb-server] Introduce Socket::Initialize and Terminate to simply WSASocket ↵Aaron Smith2019-04-104-44/+17
| | | | | | | | | | | | | | | | setup Reviewers: zturner, labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60440 llvm-svn: 358044
* Minidump: use string parsing functionality from llvmPavel Labath2019-04-091-57/+74
| | | | llvm-svn: 357977
* Breakpad: Parse Stack CFI recordsPavel Labath2019-04-091-1/+23
| | | | | | | | | | | | | | | | | Summary: This patch adds support for parsing STACK CFI records from breakpad files. The expressions specifying the values of registers are not parsed.The idea is that these will be handed off to the postfix expression -> dwarf compiler, once it is extracted from the internals of the NativePDB plugin. Reviewers: clayborg, amccarth, markmentovai Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D60268 llvm-svn: 357975
* MinidumpParser: parse SystemInfo stream via llvmPavel Labath2019-04-081-3/+56
| | | | | | | I also update the tests for SystemInfo parsing to use the yaml2minidump capabilities in llvm instead of relying on checked-in binaries. llvm-svn: 357896
* MinidumpParser: use minidump parser in llvm/ObjectPavel Labath2019-04-054-22/+22
| | | | | | | | | | | | | | | | | | This patch removes the lower layers of the minidump parsing code from the MinidumpParser class, and replaces it with the minidump parser in llvm. Not all functionality is already avaiable in the llvm class, but it is enough for us to be able to stop enumerating streams manually, and rely on the minidump directory parsing code from the llvm class. This also removes some checked-in binaries which were used to test error handling in the parser, as the error handling is now done (and tested) in llvm. Instead I just add one test that ensures we correctly propagate the errors reported by the llvm parser. The input for this test can be written in yaml instead of a checked-in binary. llvm-svn: 357748
* Breakpad: Refine record classification codePavel Labath2019-04-041-2/+7
| | | | | | | | | | | | | | | | | Previously we would classify all STACK records into a single bucket. This is not really helpful, because there are three distinct types of records beginning with the token "STACK" (STACK CFI INIT, STACK CFI, STACK WIN). To be consistent with how we're treating other records, we should classify these as three different record types. It also implements the logic to put "STACK CFI INIT" and "STACK CFI" records into the same "section" of the breakpad file, as they are meant to be read together (similar to how FUNC and LINE records are treated). The code which performs actual parsing of these records will come in a separate patch. llvm-svn: 357691
* [Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere2019-04-031-0/+96
| | | | | | | | | | | | | | | For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not. This patch adds the missing macros and updates the lldb-instr tool. Differential revision: https://reviews.llvm.org/D60178 llvm-svn: 357639
* [LLDB] - Update the test cases after yaml2obj change.George Rimar2019-04-034-158/+174
| | | | | | | | | https://reviews.llvm.org/D60122 (r357595) changed the symbols description format in yaml2obj. This change updates the LLDB tests. llvm-svn: 357600
* [CMake] Only the Python scirpt interpreter should link against Python.Jonas Devlieghere2019-04-012-8/+1
| | | | | | This patch removes spurious links against Python. llvm-svn: 357431
* [ScriptInterpreterPython] Fix the unit test after refactorJonas Devlieghere2019-03-291-3/+4
| | | | llvm-svn: 357313
* [ExpressionParser] Add swift-lldb case for finding clang resource dirAlex Langford2019-03-261-3/+2
| | | | | | | | | | | | | | Summary: I'm adding this to reduce the difference between swift-lldb and llvm.org's lldb. Reviewers: aprantl, davide, compnerd, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D59708 llvm-svn: 357030
* [Python] Define empty SWIG wrapper for unit testin"Jonas Devlieghere2019-03-262-1/+188
| | | | | | | | | The python plugin uses wrappers generated by swig. For the symbols to be available, we'd need to link against liblldb, which is not an option because the symbols could conflict with the static library we are testing. Instead we define the symbols ourselves in the unit test. llvm-svn: 356971
* [Python] Move SWIG wrapper dependency into the pluginJonas Devlieghere2019-03-251-1/+1
| | | | | | This should fix the Windows bot (fingers crossed). llvm-svn: 356967
* [PythonTestSuite] Fix usage of InitializePrivate in PythonTestSuiteJonas Devlieghere2019-03-251-3/+8
| | | | llvm-svn: 356950
* [Args] Handle backticks to prevent crash.Jonas Devlieghere2019-03-251-0/+26
| | | | | | | | | | Currently LLDB crashes when autocompleting a command that ends with a backtick because the quote character wasn't handled. This fixes that and adds a unit test for this function. Differential revision: https://reviews.llvm.org/D59779 llvm-svn: 356927
* [lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny2019-03-191-0/+2
| | | | | | | | | | | | Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB. Differential Revision: https://reviews.llvm.org/D59427 llvm-svn: 356481
* Remove dependency edges from Host to Target/Core.Zachary Turner2019-03-081-1/+0
| | | | | | After recent changes, Host is now dependency-free. llvm-svn: 355730
* [ExpressionParser] Implement ComputeClangResourceDir for WindowsAlex Langford2019-03-071-2/+5
| | | | | | | | | | | | | | | | Summary: This function is useful for expression evaluation, especially when doing swift debugging on windows. Reviewers: aprantl, labath Reviewed By: labath Subscribers: teemperor, jdoerfert, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D59072 llvm-svn: 355631
* When disassembling Aarch64 target and vendor Apple, set the cpu toJason Molenda2019-03-072-0/+81
| | | | | | | | | | | | "apple-latest" which llvm uses to indicate the newest supported ISA. Add a unit test; I'm only testing an armv8.1 instruction in this unit test which would already be disassembled correctly because we set the disassembler to ARM v8.2 mode, but it ensures that nothing has been broken by adding this cpu spec. <rdar://problem/38714781> llvm-svn: 355578
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-2/+2
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Resubmit "Don't include UnixSignals.h from Host."Zachary Turner2019-03-061-2/+7
| | | | | | | | This was reverted because it breaks the GreenDragon bot, but the reason for the breakage is lost, so I'm resubmitting this now so we can find out what the problem is. llvm-svn: 355528
* Move RangeMap.h into UtilityPavel Labath2019-03-064-5/+4
| | | | | | | | | | | | | | Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
* [ExpressionParser] Test GetClangResourceDirAlex Langford2019-03-061-12/+27
| | | | | | | | | | | | | Summary: I'm doing this because I plan on implementing `ComputeClangResourceDirectory` on windows so that `GetClangResourceDir` will work. Additionally, I made test_paths make sure that the directory member of the returned FileSpec is not none. This will fail on windows since `ComputeClangResourceDirectory` isn't implemented yet. Differential Revision: https://reviews.llvm.org/D58748 llvm-svn: 355463
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-043-2/+2
| | | | | | | | | | | | | | | | | | | | | 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-044-0/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud