summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target
Commit message (Collapse)AuthorAgeFilesLines
* [LanguageRuntime] Simplify CreateExceptionSearchFilter in derived classesAlex Langford2019-06-111-3/+0
| | | | llvm-svn: 363109
* Add support to read aux vector valuesAntonio Afonso2019-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499 I need to read the aux vector to know where the r_debug map with the loaded libraries are. The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin. Reviewers: clayborg, xiaobai, labath, JDevlieghere Reviewed By: clayborg, labath, JDevlieghere Subscribers: emaste, JDevlieghere, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62500 llvm-svn: 363098
* [Target] Use llvm::scope_exit to restore m_suppress_stop_hooks value.Tatyana Krasnukha2019-06-101-4/+5
| | | | llvm-svn: 362985
* [Target] Remove Process::GetObjCLanguageRuntimeAlex Langford2019-06-101-8/+0
| | | | | | | | | | | Summary: In an effort to make Process more language agnostic, I removed GetCPPLanguageRuntime from Process. I'm following up now with an equivalent change for ObjC. Differential Revision: https://reviews.llvm.org/D63052 llvm-svn: 362981
* [Target] Remove unused header from ProcessAlex Langford2019-06-081-1/+0
| | | | | | | I forgot to remove this when I removed GetCPPLanguageRuntime from Process llvm-svn: 362885
* [LanguageRuntime] Introduce LLVM-style castsAlex Langford2019-06-084-4/+7
| | | | | | | | | | | | Summary: Using llvm-style rtti gives us stronger guarantees around casting LanguageRuntimes. As discussed in D62755 Differential Revision: https://reviews.llvm.org/D62934 llvm-svn: 362884
* [Target] Remove Process::GetCPPLanguageRuntimeAlex Langford2019-06-041-10/+0
| | | | | | | | | | | | | | | | | | | | | Summary: I want to remove this method because I think that Process should be language agnostic, or at least, not have knowledge about specific language runtimes. There is "GetLanguageRuntime()" which should be used instead. If the caller a CPPLanguageRuntime, they should cast it as needed. Ideally, this should only happen in plugins that need C++ specific knowledge. The next step I would like to do is remove "GetObjCLanguageRuntime()" as well. There are a lot more instances of that function being used, so I wanted to upload this one first to get the general reception to this idea. Reviewers: compnerd, davide, JDevlieghere, jingham, clayborg, labath, aprantl Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62755 llvm-svn: 362544
* [Target] Generalize some behavior in Target::SymbolsDidLoadAlex Langford2019-06-031-6/+2
| | | | | | | | | | | | Summary: SymbolsDidLoad is currently only implemented for ObjCLanguageRuntime, but that doesn't mean that it couldn't be useful for other Langauges. Although this change seems like it's generalizing for the sake of purity, this removes Target's dependency on ObjCLanguageRuntime. Differential Revision: https://reviews.llvm.org/D62796 llvm-svn: 362461
* [Target] Adjust header in ThreadAlex Langford2019-06-021-1/+1
| | | | llvm-svn: 362318
* [Target] Remove ABI's dependence on ExpressionParserAlex Langford2019-05-311-5/+5
| | | | llvm-svn: 362259
* [Target] Generalize language-specific behavior in ThreadPlanStepThroughAlex Langford2019-05-301-16/+10
| | | | | | | | | | | | Summary: When creating a ThreadPlan to step through a trampoline, we ask the ObjC language runtime and the CPP language runtime to come up with such a thread plan if the dynamic loader fails to give us one. I don't see why this behavior can't be language agnostic. Differential Revision: https://reviews.llvm.org/D61921 llvm-svn: 362164
* [Target] Generalize Process::IsPossibleDynamicValueAlex Langford2019-05-301-5/+5
| | | | llvm-svn: 362154
* [Target] Sink some asserts into Process::GetLanguageRuntimeAlex Langford2019-05-291-5/+14
| | | | llvm-svn: 362032
* [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
OpenPOWER on IntegriCloud