summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* [Target] Introduce Process::GetLanguageRuntimesAlex Langford2019-05-293-10/+37
| | | | | | | | | | | | | | | | Summary: Currently there's not really a good way to iterate over the language runtimes a process has. This is sometimes desirable (as seen in my change to Thread). Additionally, there's not really a good reason to iterate over every available language, but rather only over languages for which we have a plugin loaded. Reviewers: JDevlieghere, davide, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62562 llvm-svn: 361999
* [Process] Clean up some logic around LanguageRuntimesAlex Langford2019-05-241-7/+10
| | | | llvm-svn: 361666
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-243-6/+6
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* [Process] Fix another thread_result_t & nullptr incompatibility.Jonas Devlieghere2019-05-231-7/+7
| | | | llvm-svn: 361548
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-235-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Target] Protect Processes' language runtimes map with a mutexAlex Langford2019-05-221-10/+22
| | | | | | | | | | | | | Summary: From what I understand, it's possible for multiple threads to request a specific language runtime (e.g. CPPLanguageRuntime). This leads to a data race. Reviewers: jingham, JDevlieghere, compnerd, clayborg Differential Revision: https://reviews.llvm.org/D62169 llvm-svn: 361442
* [Target] Stop linking against lldbPluginObjCLanguageAlex Langford2019-05-162-2/+1
| | | | llvm-svn: 360945
* Factor out switch statement into a helper function (NFC)Adrian Prantl2019-05-161-0/+18
| | | | | | This addresses post-commit review feedback for https://reviews.llvm.org/D62015. llvm-svn: 360930
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-151-12/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* [Target] Generalize some behavior in ThreadAlex Langford2019-05-151-13/+19
| | | | | | | | | | Summary: I don't think there's a good reason for this behavior to be considered ObjC-specific. We can generalize this. Differential Revision: https://reviews.llvm.org/D61776 llvm-svn: 360741
* typedef enum -> enumFangrui Song2019-05-141-2/+2
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654
* [DataFormatters] FindLibCppStdFunctionCallableInfo() currently uses ↵Shafik Yaghmour2019-05-131-2/+2
| | | | | | | | FindFunctions() in order to find a lambdas operator()() but using FindSymbolsMatchingRegExAndType() is cheaper and if we also anchor the regex using ^ this adds some additional performance gains. Differential Revision: https://reviews.llvm.org/D61759 llvm-svn: 360599
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-092-4/+6
| | | | | | | | | | calls and stepping into and them out of each one Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue. Differential Revision: https://reviews.llvm.org/D58678 llvm-svn: 360375
* Propagate command interpreter errors from lldlbinitJonas Devlieghere2019-05-081-0/+1
| | | | | | | | | | | | | | This patch ensures that we propagate errors coming from the lldbinit file trough the command/script interpreter. Before, if you did something like command script import syntax_error.py, and the python file contained a syntax error, lldb wouldn't tell you about it. This changes with the current patch: errors are now propagated by default. PS: Jim authored this change and I added testing. Differential revision: https://reviews.llvm.org/D61579 llvm-svn: 360216
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-063-10/+19
| | | | | | | | | | | | | | | | | | | | | | | 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-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
* Hide runtime support values such as clang's __vla_expr from frame variableAdrian Prantl2019-05-022-1/+41
| | | | | | | | | | | | by respecting the "artificial" attribute on variables. Function arguments that are artificial and useful to end-users are being whitelisted by the language runtime. <rdar://problem/45322477> Differential Revision: https://reviews.llvm.org/D61451 llvm-svn: 359841
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-262-12/+4
| | | | | | | | | | | | | | 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
* Lock accesses to OptionValueFileSpecList objectsFrederic Riss2019-04-233-13/+23
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a bug in my change to ModulesDidLoad in r357955.Jason Molenda2019-04-221-5/+3
| | | | | | | | | | | | | In the process of hoisting the LoadScriptingResourceForModule out of Target::ModuleAdded and into Target::ModulesDidLoad, I had ModulesDidLoad fetching the Target's entire image list and look for scripting resources in those -- instead of only looking for scripting resources in the modules that had been added to the target's image list. <rdar://problem/50065315> llvm-svn: 358929
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1032-109/+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
* Rename Target::GetSharedModule to Target::GetOrCreateModule.Jason Molenda2019-04-081-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a flag to control whether the ModulesDidLoad notification is called when a module is added. If the notifications are disabled, the caller must call ModulesDidLoad after adding all the new modules, but postponing this notification until they're all batched up can allow for better efficiency than notifying one-by-one. Change the name of the ModuleList notifier functions that a subclass can implement to start with 'Notify' to make it clear what they are. Add a NotifyModulesRemoved. Add header documentation for the changed/updated methods. Added defaulted-value 'notify' argument to ModuleList Append, AppendIfNeeded, and Remove because callers working with a local ModuleList don't have an obvious idea of what notify means in this context. When the ModuleList is a part of the Target class, the notify behavior matters. DynamicLoaderDarwin has been updated so that libraries being added/removed are correctly batched up before notifications are sent. Added the TestModuleLoadedNotifys.py test to run on Darwin to test this. <rdar://problem/48293064> Differential Revision: https://reviews.llvm.org/D60172 llvm-svn: 357955
* Unify random timeouts throughout LLDB and make them configurable.Adrian Prantl2019-04-051-6/+18
| | | | | | | | | | | | | | | | | 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
* [Process] Use early returns in Process::WriteMemory (NFC)Jonas Devlieghere2019-04-011-55/+51
| | | | | | | | | | I found the code of Process::WriteMemory particularly hard to follow when reviewing Ismail's change in D60022. This simplifies the code and hopefully prevents similar oversights in the future. Differential revision: https://reviews.llvm.org/D60092 llvm-svn: 357428
* [Process] Fix WriteMemory return valueMed Ismail Bennani2019-04-011-2/+3
| | | | | | | | | | | | | | | | | | | | | Summary: In case of a breakpoint site overlapping with the destination address, the WriteMemory method reported an incorrect memory size. Instead of returning the right amount of bytes written, it falls through the scope and returned 0. Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com> Reviewers: jasonmolenda, friss, jingham Subscribers: JDevlieghere, davide, lldb-commits, #lldb Tags: #lldb Differential Revision: https://reviews.llvm.org/D60022 llvm-svn: 357420
* Use the multi-lockable form of std::lock for operator=Jim Ingham2019-03-292-4/+7
| | | | | | | | | | | For = operators for lists that have mutexes, we were either just taking the locks sequentially or hand-rolling a trick to try to avoid lock inversion. Use the std::lock mechanism for this instead. Differential Revision: https://reviews.llvm.org/D59957 llvm-svn: 357276
* [NFC] find_first_of/find_last_of -> find/rfind for single char.Jonas Devlieghere2019-03-281-1/+1
| | | | | | | | | For a single char argument, find_first_of is equal to find and find_last_of is equal to rfind. While playing around with the plugin stuff this caused an export failure because it always got inlined except once, which resulted in an undefined symbol. llvm-svn: 357198
* [StackFrameRecognizer] Remove unneeded LLDB_DISABLE_PYTHON.Davide Italiano2019-03-191-4/+0
| | | | llvm-svn: 356486
* Add ability to import std module into expression parser to improve C++ debuggingRaphael Isemann2019-03-121-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a crasher in StackFrame::GetValueForVariableExpressionPath()Greg Clayton2019-03-111-1/+6
| | | | | | | | There was a crash that would happen if an IDE would ask for a child of a shared pointer via any SB API call that ends up calling StackFrame::GetValueForVariableExpressionPath(). The previous code expects an error to be set describing why the synthetic child of a type was not able to be found, but we have some synthetic child providers that weren't setting the error and returning an empty value object shared pointer. This fixes that to ensure we don't lose our debug session by crashing, fully tests GetValueForVariableExpressionPath functionality, and ensures we don't crash on GetValueForVariableExpressionPath() in the future. Differential Revision: https://reviews.llvm.org/D59200 llvm-svn: 355850
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-111-7/+7
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Add parens to force the order of operations in an expression tryingJason Molenda2019-03-091-1/+1
| | | | | | | | | | | to do "databuffer + offset" so that we don't overflow the uint64_t's we're using for addresses when working with high addresses. Found with clang's ubsan while doing darwin kernel debugging. <rdar://problem/48728940> llvm-svn: 355761
* [lldb-vscode] Report an error if an invalid program is specified.Zachary Turner2019-03-081-92/+96
| | | | | | | | | | | | | | | Previously if an invalid program was specified, there was a bug which, when we attempted to launch the program, would report that the operation succeeded, causing LLDB to then hang while waiting indefinitely to receive some events from the process. After this patch, when an invalid program is specified, we immediately return to vs code with an error message that indicates that the program can not be found. Differential Revision: https://reviews.llvm.org/D59114 llvm-svn: 355656
* Pass ConstString by value (NFC)Adrian Prantl2019-03-069-39/+39
| | | | | | | | | | | | | | | | | 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-062-2/+9
| | | | | | | | 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-061-2/+1
| | | | | | | | | | | | | | 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
* Remove tautological #ifdefs (NFC)Adrian Prantl2019-03-051-8/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D58838 llvm-svn: 355457
* [Expression] Remove unused parameter from EvaluateAlex Langford2019-03-051-6/+5
| | | | llvm-svn: 355375
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-041-201/+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-043-101/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Resubmit r354706 with a fix for process launch.Jim Ingham2019-03-012-35/+66
| | | | | | | | | | | | | | | When the debugger is run in sync mode, you need to be able to tell whether a hijacked resume is for some special purpose (like waiting for the SIGSTOP on attach) or just to perform a synchronous resume. Target::Launch was doing that wrong, and that caused stop-hooks on process launch in source files to behave incorrectly. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58727 llvm-svn: 355213
* Revert r354706 - lit touched my thighJim Ingham2019-02-232-46/+14
| | | | llvm-svn: 354711
* Make sure that stop-hooks run asynchronously.Jim Ingham2019-02-232-14/+46
| | | | | | | | | | | | | | They aren't designed to nest recursively, so this will prevent that. Also add a --auto-continue flag, putting "continue" in the stop hook makes the stop hooks fight one another in multi-threaded programs. Also allow more than one -o options so you can make more complex stop hooks w/o having to go into the editor. <rdar://problem/48115661> Differential Revision: https://reviews.llvm.org/D58394 llvm-svn: 354706
* Revert "Don't include UnixSignals.h from Host."Davide Italiano2019-02-152-9/+2
| | | | | | It broke the modules green dragon buildbot. llvm-svn: 354177
* Don't include UnixSignals.h from Host.Zachary Turner2019-02-152-2/+9
| | | | | | | | | | | | | | | | | Host had a function to get the UnixSignals instance corresponding to the current host architecture. This means that Host had to include a file from Target. To break this dependency, just make this a static function directly in UnixSignals. We already have the function UnixSignals::Create(ArchSpec) anyway, so we just need to have UnixSignals::CreateForHost() which determines which value to pass for the ArchSpec. The goal here is to eventually break the Host->Target->Host circular dependency. Differential Revision: https://reviews.llvm.org/D57780 llvm-svn: 354168
* [lldb-server] Add remote platform capabilities for WindowsAaron Smith2019-02-141-1/+155
| | | | | | | | | | | | | | | | | | 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-1311-107/+107
| | | | | | | | | | | | | | | | | 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-122-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Remove redundant ::get() for smart pointer. (NFC)Jonas Devlieghere2019-02-124-4/+4
| | | | | | | | This commit removes redundant calls to smart pointer’s ::get() method. https://clang.llvm.org/extra/clang-tidy/checks/readability-redundant-smartptr-get.html llvm-svn: 353795
* [Thread] Update the correct variableJonas Devlieghere2019-02-121-4/+2
| | | | | | | The new shared pointer was assigning to the temporary instead of the member (m_curr_frames_sp). llvm-svn: 353783
OpenPOWER on IntegriCloud