summaryrefslogtreecommitdiffstats
path: root/lldb/source/Commands
Commit message (Collapse)AuthorAgeFilesLines
...
* Add char8_t support (C++20)Jonas Devlieghere2019-08-211-0/+2
| | | | | | | | | | | | This patch adds support for the char8_t type introduced in C++20 char8_t. The original patch was submitted by James Blachly on the LLDB mailing list [1]. I modified the patch a bit and added a test. [1] http://lists.llvm.org/pipermail/lldb-dev/2019-August/015393.html Differential revision: https://reviews.llvm.org/D66447 llvm-svn: 369582
* [lldb] Add tests for 'settings remove' and fix error message typosRaphael Isemann2019-08-211-3/+3
| | | | llvm-svn: 369524
* [lldb] Add tests for setting completions and enable 'settings remove' completionRaphael Isemann2019-08-211-0/+2
| | | | llvm-svn: 369521
* [lldb] D66174 `RegularExpression` cleanupJan Kratochvil2019-08-203-17/+19
| | | | | | | | | | I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex. Differential Revision: https://reviews.llvm.org/D66392 llvm-svn: 369352
* [lldb][NFC] Remove StringList::AutoCompleteRaphael Isemann2019-08-191-6/+12
| | | | | | | We don't need this very specific function in StringList that we only call once in LLDB. llvm-svn: 369242
* [lldb][NFC] Use GetMaxStringLength in CommandObjectApropos::DoExecuteRaphael Isemann2019-08-191-5/+1
| | | | llvm-svn: 369240
* [lldb][NFC] Address review comments to StringList for-loop supportRaphael Isemann2019-08-191-3/+2
| | | | llvm-svn: 369237
* [Utility] Reimplement RegularExpression on top of llvm::RegexJonas Devlieghere2019-08-162-11/+7
| | | | | | | | | | | | | | | Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I noticed that there are several places where need the regular expression string. So instead I propose to keep the RegularExpression class and make it a thin wrapper around llvm::Regex. This patch also removes the workaround for empty regular expressions. The result is that we are now (more or less) POSIX conformant. Differential revision: https://reviews.llvm.org/D66174 llvm-svn: 369153
* [lldb][NFC] Allow for-ranges on StringListRaphael Isemann2019-08-164-16/+8
| | | | llvm-svn: 369113
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-143-4/+4
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* [CommandObject] Remove unused functionJonas Devlieghere2019-08-071-2/+0
| | | | llvm-svn: 368208
* [Driver] Expand the executable path in the target create outputJonas Devlieghere2019-08-071-1/+2
| | | | | | | | | | | | | | | | | | Resolve the path in the target create output. This is nice when passing relative paths to the lldb command line driver. $ lldb ./binary (lldb) target create "./binary" Current executable set to '/absolute/path/to/binary' (x86_64). This change only affects the target create output and does not change the debugger's behavior. It doesn't resolve symbolic links so it won't cause confusing when debugging something like clang++ that's symlinked to clang. Differential revision: https://reviews.llvm.org/D65611 llvm-svn: 368182
* SymbolVendor: Remove passthrough methodsPavel Labath2019-08-061-7/+5
| | | | | | | | | | After the recent refactorings the SymbolVendor passthrough no longer serve any purpose. This patch removes those methods, and updates all callsites to go to the symbol file directly -- in most cases that just means calling GetSymbolFile()->foo() instead of GetSymbolVendor()->foo(). llvm-svn: 368001
* Remove SymbolVendor::GetSymtabPavel Labath2019-08-051-45/+38
| | | | | | | | | | | | | | | | | | | | Summary: This patch removes the GetSymtab method from the SymbolVendor, which is a no-op as it's implementation just forwards to the relevant SymbolFile. Instead it creates a Module::GetSymtab, which calls the SymbolFile method directly. All callers have been updated to use the Module method directly instead of a two phase GetSymbolVendor->GetSymtab search, which leads to reduced intentation in a lot of deeply nested code. Reviewers: clayborg, JDevlieghere, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D65569 llvm-svn: 367820
* SymbolVendor: Introduce Module::GetSymbolFilePavel Labath2019-08-021-49/+45
| | | | | | | | | | | | | | | | | | | | | 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-025-45/+98
| | | | | | | | | | 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 completion for functions in anonymous namespacesJonas Devlieghere2019-07-311-1/+5
| | | | | | | | | | | | | | | | | I was going through some of the old bugs and came across PR21069 which I was able to reproduce. The issue is that we match the regex `^foo` against the `DW_AT_name` in the DWARF, which for our anonymous function is indeed `foo`. However, when we get the function name from the symbol context, the result is `(anonymous namespace)::foo()`. This throws off completions, which assumes that it's appending to whatever is already present on the input, resulting in a bogus `b fooonymous\ namespace)::foo()`. Bug report: https://llvm.org/PR21069 Differential revision: https://reviews.llvm.org/D65498 llvm-svn: 367455
* [Reproducers] Fix incorrect help messageJonas Devlieghere2019-07-301-2/+2
| | | | | | | The help message mentioned the `log` command (probably because I copied it from there originally). llvm-svn: 367338
* [lldb] Also include the array definition in CommandOptions.incRaphael Isemann2019-07-2819-194/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Right now our CommandOptions.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 CommandOptions.inc generate it alongside the initializers. This patch will also allow us to generate additional declarations related to that option list in the future (e.g. a enum class representing the specific options which would make our handling code less prone). This patch also fixes a few option tables that didn't follow our naming style. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65331 llvm-svn: 367186
* [lldb] Don't dynamically allocate the posix option validator.Raphael Isemann2019-07-263-23/+14
| | | | | | | | We dynamically allocate the option validator which means we can't mark this list of OptionDefinitions as constexpr. It's also more complicated than necessary. llvm-svn: 367102
* [lldb] Tablegenify expr/frame/log/register/memoryRaphael Isemann2019-07-256-70/+161
| | | | llvm-svn: 367009
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-241-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [lldb] Fix build errors from tablegenify platform commitRaphael Isemann2019-07-242-9/+9
| | | | | | Forgot to stage some changes... llvm-svn: 366892
* [lldb][NFC] Tablegenify platformRaphael Isemann2019-07-242-46/+112
| | | | llvm-svn: 366891
* [lldb][NFC] Tablegenify processRaphael Isemann2019-07-232-25/+62
| | | | llvm-svn: 366804
* [lldb][NFC] Tablegenify sourceRaphael Isemann2019-07-232-19/+46
| | | | llvm-svn: 366795
* [lldb][NFC] Tablegenify disassembleRaphael Isemann2019-07-232-24/+41
| | | | llvm-svn: 366783
* [lldb][NFC] Tablegenify breakpointRaphael Isemann2019-07-223-136/+265
| | | | llvm-svn: 366673
* [lldb][NFC] Tablegenify targetRaphael Isemann2019-07-193-66/+168
| | | | llvm-svn: 366561
* [Commands] Remove unused header from CommandObjectFrameAlex Langford2019-07-191-1/+0
| | | | llvm-svn: 366517
* [lldb][NFC] Tablegenify alias/regex/history/source/scriptRaphael Isemann2019-07-182-28/+69
| | | | | | | (Converting these commands together as they are all simple commands that share the same file). llvm-svn: 366440
* [lldb][NFC] Format 'type' commands in Options.tdRaphael Isemann2019-07-181-46/+98
| | | | llvm-svn: 366426
* [lldb] Tablegenify thread commands and fix completion bug for thread step-*Raphael Isemann2019-07-182-39/+100
| | | | | | | | | | Beside turning the options into the new tablegen format, this patch also fixes that a few commands had source file completions for the "count" and "end-linenumber" arguments (which both accepted only integers). Reason for that are that somehow we added a '1' instead of our usual '0' value to the initial value for completion. llvm-svn: 366425
* [lldb][NFC] Tablegenify type commandsRaphael Isemann2019-07-182-68/+101
| | | | llvm-svn: 366415
* [lldb][NFC] Tablegenify watchpoint commandsRaphael Isemann2019-07-173-17/+46
| | | | | | | Part of the project that migrates these struct initializers to our new lldb-tablegen. llvm-svn: 366316
* [lldb] Rename Options.inc to CommandOptions.inc [NFC]Raphael Isemann2019-07-165-7/+7
| | | | | | | | It seems having two Options.inc files in the same project is giving our custom Xcode project a hard time. This patch renames the new Options.inc to CommandOptions.inc to prevent this conflict. llvm-svn: 366196
* [lldb][doc] Document how our LLDB table gen initialized optionsRaphael Isemann2019-07-151-0/+98
| | | | | | | | | | | | | | | | Summary: This patch adds documentation that should make it easier to migrate from using the old initializers to the table gen format. Reviewers: jingham Reviewed By: jingham Subscribers: abidh, lldb-commits, JDevlieghere Tags: #lldb Differential Revision: https://reviews.llvm.org/D64670 llvm-svn: 366083
* [lldb] Let table gen create command option initializers.Raphael Isemann2019-07-127-28/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We currently have man large arrays containing initializers for our command options. These tables are tricky maintain as we don't have any good place to check them for consistency and it's also hard to read (`nullptr, {}, 0` is not very descriptive). This patch fixes this by letting table gen generate those tables. This way we can have a more readable syntax for this (especially for all the default arguments) and we can let TableCheck check them for consistency (e.g. an option with an optional argument can't have `eArgTypeNone`, naming of flags', etc.). Also refactoring the related data structures can now be done without changing the hundred of option initializers. For example, this line: ``` {LLDB_OPT_SET_ALL, false, "hide-aliases", 'a', OptionParser::eNoArgument, nullptr, {}, 0, eArgTypeNone, "Hide aliases in the command list."}, ``` becomes this: ``` def hide_aliases : Option<"hide-aliases", "a">, Desc<"Hide aliases in the command list.">; ``` For now I just moved a few initializers to the new format to demonstrate the change. I'll slowly migrate the other option initializers tables in separate patches. Reviewers: JDevlieghere, davide, sgraenitz Reviewed By: JDevlieghere Subscribers: jingham, xiaobai, labath, mgorny, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64365 llvm-svn: 365908
* [Expression] Add PersistentExpressionState::GetCompilerTypeFromPersistentDeclAlex Langford2019-06-122-36/+61
| | | | | | | | | | | | | | | | Summary: PersistentStateExpressions (e.g. ClangPersistentVariables) have the ability to define types using expressions that persist throughout the debugging session. GetCompilerTypeFromPersistentDecl is a useful operation to have if you need to use any of those persistently declared types, like in CommandObjectMemory. This decouples clang from CommandObjectMemory and decouples Plugins from Commands in general. Differential Revision: https://reviews.llvm.org/D62797 llvm-svn: 363183
* [Commands] Remove unused headerAlex Langford2019-06-021-1/+0
| | | | llvm-svn: 362339
* [Commands] Stop hardcoding languages in CommandObjectTypeAlex Langford2019-05-311-14/+9
| | | | llvm-svn: 362268
* [Commands] Remove commented out codeAlex Langford2019-05-291-4/+0
| | | | llvm-svn: 362042
* [FuncUnwinders] Use "symbol file" unwind plans for unwindingPavel Labath2019-05-241-1/+1
| | | | | | | | | | | | | | | | | Summary: Previous patch (r360409) introduced the "symbol file unwind plan" concept, but that plan wasn't used for unwinding yet. With this patch, we start to consider the new plan as a possible strategy for both synchronous and asynchronous unwinding. I also add a test that asserts that unwinding via breakpad STACK CFI info works end-to-end. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, amccarth, markmentovai Differential Revision: https://reviews.llvm.org/D61853 llvm-svn: 361618
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-243-3/+3
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* typedef enum -> enumFangrui Song2019-05-141-6/+3
| | | | | | | | Reviewed By: labath Differential Revision: https://reviews.llvm.org/D61883 llvm-svn: 360654
* Merge target and launch info environmentsJonas Devlieghere2019-05-131-1/+4
| | | | | | | | | | | Before this change we were overriding the launch info environment with the target environment. This meant that the environment variables passed to `process launch --environment <>` were lost. Instead of replacing the environment, we should merge them. Differential revision: https://reviews.llvm.org/D61864 llvm-svn: 360612
* Remove commented-out codeJonas Devlieghere2019-05-131-43/+0
| | | | llvm-svn: 360611
* FuncUnwinders: Add a new "SymbolFile" unwind planPavel Labath2019-05-101-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: some unwind formats are specific to a single symbol file and so it does not make sense for their parsing code live in the general Symbol library (as is the case with eh_frame for instance). This is the case for the unwind information in breakpad files, but the same will probably be true for PDB unwind info (once we are able to parse that). This patch adds the ability to fetch an unwind plan provided by a symbol file plugin, as discussed in the RFC at <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. I've kept the set of changes to a minimum, as there is no way to test them until we have a symbol file which implements this API -- that is comming in a follow-up patch, which will also implicitly test this change. The interesting part here is the introduction of the "RegisterInfoResolver" interface. The reason for this is that breakpad needs to be able to resolve register names (which are present as strings in the file) into register enums so that it can construct the unwind plan. This is normally done via the RegisterContext class, handing this over to the SymbolFile plugin would mean that it has full access to the debugged process, which is not something we want it to have. So instead, I create a facade, which only provides the ability to query register names, and hide the RegisterContext behind the facade. Also note that this only adds the ability to dump the unwind plan created by the symbol file plugin -- the plan is not used for unwinding yet -- this will be added in a third patch, which will add additional tests which makes sure the unwinding works as a whole. Reviewers: jasonmolenda, clayborg Subscribers: markmentovai, amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D61732 llvm-svn: 360409
* Propagate command interpreter errors from lldlbinitJonas Devlieghere2019-05-084-0/+4
| | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud