summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix PC adjustment in StackFrame::GetSymbolContextJoseph Tremoulet2019-08-021-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames. Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places. Reviewers: jasonmolenda, clayborg, jfb Reviewed By: jasonmolenda Subscribers: labath, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64993 llvm-svn: 367691
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-021-43/+37
| | | | | | | | | | | | | | | | | | | | | 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
* Format OptionEnumValueElement (NFC)Jonas Devlieghere2019-08-021-31/+71
| | | | | | | | | | Reformat OptionEnumValueElement to make it easier to distinguish between its fields. This also removes the need to disable clang-format for these arrays. Differential revision: https://reviews.llvm.org/D65489 llvm-svn: 367638
* Fix issues with inferior stdout coming out of orderPavel Labath2019-07-311-63/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We've had a bug where two pieces of code, executing on two threads were attempting to write inferior output simultaneously. The first one was in Debugger::HandleProcessEvent, which handled the cases where stdout was coming while the process was running. The second was in CommandInterpreter::IOHandlerInputComplete, which was ensuring that any output is printed before the command which caused process to run terminates. Both of these things make sense, but the fact they were implemented as two independent functions without any synchronization meant that race conditions could occur (e.g. both threads call process->GetSTDOUT, get two chunks of data, but then end up calling stream->Write in opposite order). This was most apparent in situations where a process quickly writes a bunch of output and then exits (as all our register tests do). This patch adds a mutex to ensure that stdout forwarding happens atomically. It also refactors a code somewhat in order to reduce code duplication. Reviewers: clayborg, jingham Subscribers: jfb, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D65152 llvm-svn: 367418
* [CompletionRequest] Remove unimplemented members.Jonas Devlieghere2019-07-312-13/+7
| | | | | | | | | | Completion requests have two fields that are essentially unimplemented: `m_match_start_point` and `m_max_return_elements`. This would've been okay, if it wasn't for the fact that this caused a bunch of useless parameters to be passed around. Occasionally there would be a comment or assert saying that they are not supported. This patch removes them. llvm-svn: 367385
* [StringList] Change LongestCommonPrefix APIJonas Devlieghere2019-07-311-2/+1
| | | | | | | | | When investigating a completion bug I got confused by the API. LongestCommonPrefix finds the longest common prefix of the strings in the string list. Instead of returning that string through an output argument, just return it by value. llvm-svn: 367384
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-302-9/+15
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* [lldb] Fix crash when tab-completing in multi-line exprRaphael Isemann2019-07-301-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Tab completing inside the multiline expression command can cause LLDB to crash. The easiest way to do this is to go inside a frame with at least one local variable and then try to complete: (lldb) expr 1. a[tab] Reason for this was some mixup when we calculate the cursor position. Obviously we should calculate the offset inside the string by doing 'end - start', but we are doing 'start - end' (which causes the offset to become -1 which will lead to some out-of-bounds reading). Fixes rdar://51754005 I don't see any way to test this as the *multiline* expression completion is completely untested at the moment and I don't think we have any existing code for testing infrastructure for it. Reviewers: shafik, davide, labath Reviewed By: labath Subscribers: abidh, lldb-commits, davide, clayborg, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D64995 llvm-svn: 367308
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-294-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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-292-22/+18
| | | | | | | | | | | | | | | | 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
* [TableGen] Fix stale include pathsJonas Devlieghere2019-07-262-8/+8
| | | | | | | This worked locally because the include files were not regenerated, but fails when performing a clean build. llvm-svn: 367152
* [TableGen] Move core properties into a separate file (NFC)Jonas Devlieghere2019-07-262-1/+129
| | | | | | | With the plugins having their own tablgen file, it makes sense to split off the core properties as well. llvm-svn: 367140
* Let tablegen generate property definitionsJonas Devlieghere2019-07-253-128/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* SymbolVendor: Remove the type list memberPavel Labath2019-07-251-7/+0
| | | | | | | | | | | | | | | | | | | | | Summary: Similarly to the compile unit lists, the list of types can also be managed by the symbol file itself. Since the only purpose of this list seems to be to maintain an owning reference to all the types a symbol file has created (items are only ever added to the list, never retrieved), I remove the passthrough functions in SymbolVendor and Module. I also tighten the interface of the function (return a reference instead of a pointer, make it protected instead of public). Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65135 llvm-svn: 366994
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-249-170/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Logging] Fix format stringsJonas Devlieghere2019-07-231-10/+10
| | | | | | | Change format strings to use the `{}` syntax instead of the printf syntax when using LLDB_LOG. llvm-svn: 366824
* [Logging] Replace LogIfAnyCategoriesSet with LLDB_LOG.Jonas Devlieghere2019-07-221-26/+24
| | | | | | | | This patch removes any remaining instances of LogIfAnyCategoriesSet and replaces them with the LLDB_LOG macro. This in turn made it possible to make Log::VAPrintf and Log::VAError private. llvm-svn: 366768
* [Symbol] Improve Variable::GetLanguageAlex Langford2019-07-221-10/+1
| | | | | | | | | | | | | | | | Summary: When trying to ascertain what language a variable belongs to, just checking the compilation unit is often not enough. In r364845 I added a way to check for a variable's language type, but didn't put it in Variable itself. Let's go ahead and put it in Variable. Reviewers: jingham, clayborg Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D64042 llvm-svn: 366733
* check for interrupt from fgets on WindowsNathan Lanza2019-07-191-0/+3
| | | | | | | | Windows does not have the error EINTR when a blocking syscall is interrupted by a signal. The ReadFile API that fgets is implemented with instead use ERROR_OPERATION_ABORTED. Check for that after fgets. llvm-svn: 366520
* [FileSpecList] Add EmplaceBack method (NFC)Jonas Devlieghere2019-07-181-3/+3
| | | | | | | | 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
* add a workaround in GetLine to account for ReadFile not reporintg errorNathan Lanza2019-07-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: ReadFile on Windows is supposed to set ERROR_OPERATION_ABORTED according to the docs on MSDN. However, this has evidently been a known bug since Windows 8. Therefore, we can't detect if a signal interrupted in the fgets. So pressing ctrl-c causes the repl to end and the process to exit. A temporary workaround is just to attempt to fgets twice until this bug is fixed. A possible alternative would be to set a flag in the `sigint_handler` and simply check that flag in the true part of the if statement. However, signal handlers on Windows are asynchronous and this would require sleeping on the repl loop thread while still not necessarily guarnateeing that you caught the sigint. Reviewers: jfb Differential Revision: https://reviews.llvm.org/D64660 llvm-svn: 366281
* [Core] Generalize ValueObject::MaybeCalculateCompleteTypeAlex Langford2019-07-121-42/+11
| | | | | | | | | | | | | | | | Summary: Instead of hardcoding ClangASTContext and ObjCLanguageRuntime, we can generalize this by creating the method GetRuntimeType in LanguageRuntime and moving the current MaybeCalculateCompleteType implementation into ObjCLanguageruntime::GetRuntimeType Reviewers: jingham, clayborg, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D64159 llvm-svn: 365939
* Change LaunchThread interface to return an expected.Jonas Devlieghere2019-07-052-7/+37
| | | | | | | | | Change the interface to return an expected, instead of taking a Status pointer. Differential revision: https://reviews.llvm.org/D64163 llvm-svn: 365226
* [Core] Generalize ValueObject::IsRuntimeSupportValueAlex Langford2019-07-011-11/+21
| | | | | | | | | | | | | | | Summary: Instead of falling back to ObjCLanguageRuntime, we should be falling back to every loaded language runtime. This makes ValueObject more language agnostic. Reviewers: labath, compnerd, JDevlieghere, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D63240 llvm-svn: 364845
* [Target] Decouple ObjCLanguageRuntime from LanguageRuntimeAlex Langford2019-06-211-1/+13
| | | | | | | | | | | | Summary: ObjCLanguageRuntime was being pulled into LanguageRuntime because of Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint, we can extend the LanguageRuntime plugin interface so that LanguageRuntimes can give us a BreakpointPrecondition for exceptions. Differential Revision: https://reviews.llvm.org/D63181 llvm-svn: 364098
* Add color to the default thread and frame format.Jonas Devlieghere2019-06-172-13/+20
| | | | | | | | | | | | | | Now that we correctly ignore ASCII escape sequences when colors are disabled (r362240), I'd like to change the default frame and thread format to include color in their output, in line with the syntax highlighting that Raphael added a while ago. This patch adds highlighting for the stop reason, the file, line and column number. With colors disabled, this of course is a no-op. Differential revision: https://reviews.llvm.org/D62743 llvm-svn: 363608
* [lldb] [test] Extend D55859 symbols.enable-external-lookup=false for more ↵Jan Kratochvil2019-06-171-0/+5
| | | | | | | | | | | | | | | | | | | | | | testcases D55859 <https://reviews.llvm.org/D55859> has no effect for some of the testcases so this patch extends it even for (all?) other testcases known to me. LLDB was failing when LLDB prints errors reading system debug infos (`*-debuginfo.rpm`, DWZ-optimized) which should never happen as LLDB testcases should not be affected by system debug infos. `lldb/packages/Python/lldbsuite/test/api/multithreaded/driver.cpp.template` is using only SB API which does not expose `ModuleList` so I had to call `HandleCommand()` there. `lldb-test.cpp` could also use `HandleCommand` and then there would be no need for `ModuleListProperties::SetEnableExternalLookup()` but I think it is cleaner with API and not on based on text commands. Differential Revision: https://reviews.llvm.org/D63339 llvm-svn: 363567
* Recognise debug_types.dwo as a debug info sectionPavel Labath2019-06-121-0/+2
| | | | | | This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
* [Target] Remove Process::GetObjCLanguageRuntimeAlex Langford2019-06-101-3/+2
| | | | | | | | | | | 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
* [FormatEntity] Ignore ASCII escape sequences when colors are disabled.Jonas Devlieghere2019-05-311-12/+15
| | | | | | | | | This patch makes the FormatEntity honor the debugger's color settings by not inserting ASCII escape sequences when colors are disabled. Differential revision: https://reviews.llvm.org/D62714 llvm-svn: 362240
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-241-1/+1
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* Test commit access by removing a empty lineAntonio Afonso2019-05-231-1/+0
| | | | llvm-svn: 361531
* [lldb] fix cannot convert from 'nullptr' to 'lldb::thread_result_t'Konrad Kleine2019-05-232-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: On Windows `lldb::thread_result_t` resolves to `typedef unsigned thread_result_t;` and on other platforms it resolves to `typedef void *thread_result_t;`. Therefore one cannot use `nullptr` when returning from a function that returns `thread_result_t`. I've made this change because a windows build bot fails with these errors: ``` E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type ``` and ``` E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t' E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type ``` This is the failing build: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5035/steps/build/logs/stdio Reviewers: JDevlieghere, teemperor, jankratochvil, labath, clayborg, RKSimon, courbet, jhenderson Reviewed By: labath, clayborg Subscribers: labath, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62305 llvm-svn: 361503
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-2311-89/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Delete unnecessary copy ctorsFangrui Song2019-05-221-3/+0
| | | | llvm-svn: 361358
* Factor out switch statement into a helper function (NFC)Adrian Prantl2019-05-161-10/+4
| | | | | | This addresses post-commit review feedback for https://reviews.llvm.org/D62015. llvm-svn: 360930
* Make sure GetObjectDescription falls back to the Objective-C runtime.Adrian Prantl2019-05-161-27/+29
| | | | | | | | | | | | | This fixes an unintended regression introduced by https://reviews.llvm.org/D61451 by making sure the Objective-C runtime is also tried when the "correct" language runtime failed to return an object description. rdar://problem/50791055 Differential Revision: https://reviews.llvm.org/D62015 llvm-svn: 360929
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-153-24/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* Revert "Disable the step over skipping calls feature since buildbots are not ↵Pavel Labath2019-05-101-2/+2
| | | | | | | | | | | | | | | | happy." While this fixed the windows bot failures, it also broke all other bots. Upon closer inspection, it turns out that the windows bots were "broken" because two tests were unexpectedly passing -- i.e., the original patch (r360375) actually improved our stepping support on windows. So instead, I remove the relevant XFAILs. This reverts commit r360397. llvm-svn: 360407
* Disable the step over skipping calls feature since buildbots are not happy.Greg Clayton2019-05-101-2/+2
| | | | llvm-svn: 360397
* Improve step over performance by not stopping at branches that are function ↵Greg Clayton2019-05-091-1/+4
| | | | | | | | | | 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
* [Core] Remove unused dependenciesAlex Langford2019-05-071-2/+0
| | | | llvm-svn: 360193
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-061-0/+18
| | | | | | | | | | | | | | | | | | | | | | | 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
* Supply a default implementation of IsRuntimeSupportValue.Adrian Prantl2019-05-031-0/+4
| | | | | | Thanks to Pavel for pointing this out. llvm-svn: 359925
* [FormatEntity] Remove unused format type (NFC)Jonas Devlieghere2019-04-271-98/+84
| | | | | | | The FormatType enum and corresponding field are unused. This patch removes the type, field and simplifies the macros that initialize them. llvm-svn: 359372
* [ScriptInterpreter] Move ownership into debugger (NFC)Jonas Devlieghere2019-04-263-11/+21
| | | | | | | | | | | | | | 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
* [CommandInterpreter] Remove scripting language argument. (NFC)Jonas Devlieghere2019-04-261-2/+2
| | | | | | | | | | The script language argument was passed from the debugger to the command interpreter, only to call SetScriptLanguage on the debugger again. It wasn't even used to initialize the script interpreter, because that would query the debugger again. This patch removes the needless back and forth. llvm-svn: 359346
* [ScriptInterpreter] Pass the debugger instead of the command interpreterJonas Devlieghere2019-04-261-4/+5
| | | | | | | | | | | | | | | | As discussed in D61090, there's no good reason for the script interpreter to depend on the command interpreter. When looking at the code, it becomes clear that we mostly use the command interpreter as a way to access the debugger. Hence, it makes more sense to just pass that to the script interpreter directly. This is part 1 out of 2. I have another patch in the pipeline that changes the ownership of the script interpreter to the debugger as well, but I didn't get around to finish that today. Differential revision: https://reviews.llvm.org/D61172 llvm-svn: 359330
* Correctly check if a warning message lacks a trailing new lineRaphael Isemann2019-04-161-3/+3
| | | | | | | | | | | | | | | | Summary: Fixes LLVM bug 41489. Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60653 llvm-svn: 358477
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1017-100/+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
OpenPOWER on IntegriCloud