aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Commands/CommandObjectTarget.cpp
AgeCommit message (Collapse)AuthorFilesLines
2021-09-21[lldb] Add --stack option to `target symbols add` commandJonas Devlieghere1-2/+70
Currently you can ask the target symbols add command to locate the debug symbols for the current frame. This patch add an options to do that for the whole call stack. Differential revision: https://reviews.llvm.org/D110011
2021-09-20[lldb] Extract adding symbols for UUID/File/Frame (NFC)Jonas Devlieghere1-89/+111
This moves the logic for adding symbols based on UUID, file and frame into little helper functions. This is in preparation for D110011. Differential revision: https://reviews.llvm.org/D110010
2021-09-20[lldb] Fix whitespace in CommandObjectTarget (NFC)Jonas Devlieghere1-12/+12
2021-08-09[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compatMichał Górny1-2/+2
Modify OpenOptions enum to open the future path into synchronizing vFile:open bits with GDB. Currently, LLDB and GDB use different flag models effectively making it impossible to match bits. Notably, LLDB uses two bits to indicate read and write status, and uses union of both for read/write. GDB uses a value of 0 for read-only, 1 for write-only and 2 for read/write. In order to future-proof the code for the GDB variant: 1. Add a distinct eOpenOptionReadWrite constant to be used instead of (eOpenOptionRead | eOpenOptionWrite) when R/W access is required. 2. Rename eOpenOptionRead and eOpenOptionWrite to eOpenOptionReadOnly and eOpenOptionWriteOnly respectively, to make it clear that they do not mean to be combined and require update to all call sites. 3. Use the intersection of all three flags when matching against the three possible values. This commit does not change the actual bits used by LLDB. Differential Revision: https://reviews.llvm.org/D106984
2021-08-05[lldb] Use a struct to pass function search options to Module::FindFunctionJonas Devlieghere1-13/+16
Rather than passing two booleans around, which is especially error prone with them being next to each other, use a struct with named fields instead. Differential revision: https://reviews.llvm.org/D107295
2021-07-02[lldb] Replace default bodies of special member functions with = default;Jonas Devlieghere1-2/+2
Replace default bodies of special member functions with = default; $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix , https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html Differential revision: https://reviews.llvm.org/D104041
2021-06-22[lldb] Remove more redundant SetStatus(eReturnStatusFailed)David Spickett1-7/+2
Mostly by converting uses of GetErrorStream to AppendError, so that the call to SetStatus is implicit. Some remain where it isn't certain that you'll have a message to set, or you want the output to be on stdout. One place in CommandObjectWatchpoint previously didn't set the status to failed at all. However it's pretty obvious that it should do so. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D104697
2021-06-17[lldb] Remove redundant calls to set eReturnStatusFailedDavid Spickett1-73/+0
This is part 2, covering the commands source. Some uses remain where it's tricky to see what the logic is or they are not used with AppendError. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D104448
2021-06-09[lldb] Use C++11 default member initializersJonas Devlieghere1-22/+16
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy and the modernize-use-default-member-init check. $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix This is a mass-refactoring patch and this commit will be added to .git-blame-ignore-revs. Differential revision: https://reviews.llvm.org/D103483
2021-05-18[lldb][NFC] Remove all uses of StringRef::withNullAsEmpty in LLDBRaphael Isemann1-2/+1
A long time ago LLDB wanted to start using StringRef instead of C-Strings/ConstString but was blocked by the fact that the StringRef constructor that takes a C-string was asserting that the C-string isn't a nullptr. To workaround this, D24697 introduced a special function called `withNullAsEmpty` and that's what LLDB (and only LLDB) started to use to build StringRefs from C-strings. A bit later it seems that `withNullAsEmpty` was declared too awkward to use and instead the assert in the StringRef constructor got removed (see D24904). The rest of LLDB was then converted to StringRef by just calling the now perfectly usable implicit constructor. However, all the calls to `withNullAsEmpty` just remained and are now just strange artefacts in the code base that just look out of place. It's also curiously a LLDB-exclusive function and no other project ever called it since it's introduction half a decade ago. This patch removes all uses of `withNullAsEmpty`. The follow up will be to remove the function from StringRef. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D102597
2021-02-10[lldb] Use internal_dict name over dict in python examplesDave Lee1-1/+1
Follow up to https://reviews.llvm.org/rG483ec136da7193de781a5284f1c37929cc27c05c
2021-01-07[lldb] Access the ModuleList through iterators where possible (NFC)Jonas Devlieghere1-89/+73
Replace uses of GetModuleAtIndexUnlocked and GetModulePointerAtIndexUnlocked with the ModuleIterable and ModuleIterableNoLocking where applicable. Differential revision: https://reviews.llvm.org/D94271
2020-12-22[lldb] Abstract scoped timer logic behind LLDB_SCOPED_TIMER (NFC)Jonas Devlieghere1-2/+1
This patch introduces a LLDB_SCOPED_TIMER macro to hide the needlessly repetitive creation of scoped timers in LLDB. It's similar to the LLDB_LOG(F) macro. Differential revision: https://reviews.llvm.org/D93663
2020-12-12[lldb] "target create" shouldn't save target if the command failedTatyana Krasnukha1-107/+103
TargetList::CreateTarget automatically adds created target to the list, however, CommandObjectTargetCreate does some additional preparation after creating a target and which can fail. The command should remove created target if it failed. Since the function has many ways to return, scope guard does this work safely. Changes to the TargetList make target adding and selection more transparent. Other changes remove unnecessary SetSelectedTarget after CreateTarget. Differential Revision: https://reviews.llvm.org/D93052
2020-11-23[lldb] Prevent 'process connect' from using local-only pluginsMichał Górny1-1/+2
Add a 'can_connect' parameter to Process plugin initialization, and use it to filter plugins to these capable of remote connections. This is used to prevent 'process connect' from picking up a plugin that can only be used locally, e.g. the legacy FreeBSD plugin. Differential Revision: https://reviews.llvm.org/D91810
2020-09-29Revert "Revert "Add the ability to write target stop-hooks using the ↵Jim Ingham1-13/+100
ScriptInterpreter."" This reverts commit f775fe59640a2e837ad059a8f40e26989d4f9831. I fixed a return type error in the original patch that was causing a test failure. Also added a REQUIRES: python to the shell test so we'll skip this for people who build lldb w/o Python. Also added another test for the error printing.
2020-09-28Revert "Add the ability to write target stop-hooks using the ScriptInterpreter."Jonas Devlieghere1-100/+13
This temporarily reverts commit b65966cff65bfb66de59621347ffd97238d3f645 while Jim figures out why the test is failing on the bots.
2020-09-25Add the ability to write target stop-hooks using the ScriptInterpreter.Jim Ingham1-13/+100
Differential Revision: https://reviews.llvm.org/D88123
2020-09-21Fix reporting the lack of global variables in "target var".Jim Ingham1-0/+1
There was a little thinko which meant when stopped in a frame with debug information but whose CU didn't have any global variables we report: no debug info for frame <N> This patch fixes that error message to say the intended: no global variables in current compile unit <rdar://problem/69086361>
2020-08-25Update UnwindPlan dump to list if it is a trap handler func; also CommandJason Molenda1-1/+26
Update the "image show-unwind" command output to show if the function being shown is listed as a user-setting or platform trap handler. Update the individual UnwindPlan dumps to show whether the unwind plan is registered as a trap handler.
2020-08-24[lldb] type category name common completionGongyu Deng1-2/+0
1. Added a new common completion TypeCategoryNames to provide a list of category names for completion; 2. Applied the completion to these commands: type category delete/enable/disable/list/define; 3. Added a related test case; 4. Bound the completion to the arguments of the type 'eArgTypeName'. Reviewed By: teemperor, JDevlieghere Differential Revision: https://reviews.llvm.org/D84124
2020-08-11[lldb] stop-hook ID common completion for commands `target stop-hook ↵Gongyu Deng1-0/+20
enable/disable/delete' 1. Added a common completion StopHookIDs to provide completion with a list of stop hook ids; 2. Applied the common completion to commands: `target stop-hook delete/enable/disable'; 3. Added an related test case. Reviewed By: teemperor Differential Revision: https://reviews.llvm.org/D84123
2020-08-11[lldb] tab completion for `target modules search-paths insert​`Gongyu Deng1-0/+19
Dedicated completion for the command `target modules search-paths insert​` with a test case. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D83309
2020-07-29[lldb] Improve platform handling in CreateTargetInternalJonas Devlieghere1-1/+6
Currently, `target create` has no --platform option. However, TargetList::CreateTargetInternal which is called under the hood, will return an error when either no platform or multiple matching platforms are found, saying that a platform should be specified with --platform. This patch adds the platform option, but that doesn't solve either of these errors. - If more than one platform matches, specifying the platform isn't going to fix that. The current code will only look at the architecture instead. I've updated the error message to ask the user to specify an architecture. - If no architecture is found, specifying a new one via platform isn't going to change that either because we already try to find one that matches the given architecture. Differential revision: https://reviews.llvm.org/D84809
2020-07-28[lldb] Remove unused option '--platform-path' for 'target create'Jonas Devlieghere1-15/+0
Differential revision: https://reviews.llvm.org/D84800
2020-07-22Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)Adrian Prantl1-15/+18
This patch has no effect for C and C++. In more dynamic languages, such as Objective-C and Swift GetByteSize() needs to call into the language runtime, so it's important to pass one in where possible. My primary motivation for this is some work I'm doing on the Swift branch, however, it looks like we are also seeing warnings in Objective-C that this may resolve. Everything in the SymbolFile hierarchy still passes in nullptrs, because we don't have an execution context in SymbolFile, since SymbolFile transcends processes. Differential Revision: https://reviews.llvm.org/D84267
2020-07-16[lldb] Eliminated unused local variableAdrian McCarthy1-1/+0
I got misled by this remnant from earlier changes.
2020-07-01[lldb] Replace StringConvert with llvm::to_integer when parsing integer ↵Raphael Isemann1-23/+11
values in CommandObjects Summary: This replaces the current use of LLDB's own `StringConvert` with LLVM's `to_integer` which has a less error-prone API and doesn't use special 'error values' to designate parsing problems. Where needed I also added missing error handling code that prints a parsing error instead of continuing with the error value returned from `StringConvert` (which either gave a cryptic error message or just took the error value performed an incorrect action with it. For example, `frame recognizer delete -1` just deleted the frame recognizer at index 0). Reviewers: #lldb, labath Reviewed By: labath Subscribers: labath, abidh, JDevlieghere Differential Revision: https://reviews.llvm.org/D82297
2020-06-24[lldb] Use std::make_unique<> (NFC)Jonas Devlieghere1-2/+2
Update the rest of lldb to use std::make_unique<>. I used clang-tidy to automate this, which probably missed cases that are wrapped in ifdefs.
2020-06-02[lldb] NFC remove DISALLOW_COPY_AND_ASSIGNKonrad Kleine1-3/+9
Summary: This is how I applied my clang-tidy check (see https://reviews.llvm.org/D80531) in order to remove `DISALLOW_COPY_AND_ASSIGN` and have deleted copy ctors and deleted assignment operators instead. ``` lang=bash grep DISALLOW_COPY_AND_ASSIGN /opt/notnfs/kkleine/llvm/lldb -r -l | sort | uniq > files for i in $(cat files); do clang-tidy \ --checks="-*,modernize-replace-disallow-copy-and-assign-macro" \ --format-style=LLVM \ --header-filter=.* \ --fix \ -fix-errors \ $i; done ``` Reviewers: espindola, labath, aprantl, teemperor Reviewed By: labath, aprantl, teemperor Subscribers: teemperor, aprantl, labath, emaste, sbc100, aheejin, MaskRay, arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D80543
2020-05-14[lldb] Switch Section-dumping code to raw_ostreamPavel Labath1-3/+1
Also, add a basic test for dumping sections.
2020-05-04[lldb/Host] Improve error messages on unowned read filesMed Ismail Bennani1-56/+35
When trying to read a core file that is not owned by the user running lldb and that doesn't have read permission on the file, lldb shows a misleading error message: ``` Unable to find process plug-in for core file ``` This is due to the fact that currently, lldb doesn't check the file ownership. And when trying to to open and read a core file, the syscall fails, which prevents a process to be created. Since lldb already have a portable `open` syscall interface, lets take advantage of that and delegate the error handling to the syscall itself. This way, no matter if the file exists or if the user has proper ownership, lldb will always try to open the file, and behave accordingly to the error code returned. rdar://42630030 https://reviews.llvm.org/D78712 Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-04-02Convert for loops to entry-based iterationShivam Mittal1-16/+10
Summary: Convert index-based loops marked TODO in CommandObjectSettings and CommandObjectTarget to entry-based. Reviewers: labath Reviewed By: labath Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D76729
2020-03-31Correct the duplicate pragma marks in CommandObjectTarget.cppShivam Mittal1-2/+2
Summary: Resolve the two duplicated pragma marks in lldb/source/Commands/CommandObjectTarget.cpp Reviewers: teemperor Reviewed By: teemperor Subscribers: teemperor, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D77096
2020-03-23[lldb/Target] Rework the way the inferior environment is createdFred Riss1-0/+38
Summary: The interactions between the environment settings (`target.env-vars`, `target.inherit-env`) and the inferior life-cycle are non-obvious today. For example, if `target.inherit-env` is set, the `target.env-vars` setting will be augmented with the contents of the host environment the first time the launch environment is queried (usually at launch). After that point, toggling `target.inherit-env` will have no effect as there's no tracking of what comes from the host and what is a user setting. This patch computes the environment every time it is queried rather than updating the contents of the `target.env-vars` property. This means that toggling the `target.inherit-env` property later will now have the intended effect. This patch also adds a `target.unset-env-vars` settings that one can use to remove variables from the launch environment. Using this, you can inherit all but a few of the host environment. The way the launch environment is constructed is: 1/ if `target.inherit-env` is set, then read the host environment into the launch environment. 2/ Remove for the environment the variables listed in `target.unset-env`. 3/ Augment the launch environment with the contents of `target.env-vars`. This overrides any common values with the host environment. The one functional difference here that could be seen as a regression is that `target.env-vars` will not contain the inferior environment after launch. The patch implements a better alternative in the `target show-launch-environment` command which will return the environment computed through the above rules. Reviewers: labath, jingham Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D76470
2020-02-18[lldb][NFC] Make all CompilerDeclContext parameters references instead of ↵Raphael Isemann1-2/+3
pointers Summary: All of our lookup APIs either use `CompilerDeclContext &` or `CompilerDeclContext *` semi-randomly it seems. This leads to us constantly converting between those two types (and doing nullptr checks when going from pointer to reference). It also leads to the confusing situation where we have two possible ways to express that we don't have a CompilerDeclContex: either a nullptr or an invalid CompilerDeclContext (aka a default constructed CompilerDeclContext). This moves all APIs to use references and gets rid of all the nullptr checks and conversions. Reviewers: labath, mib, shafik Reviewed By: labath, shafik Subscribers: shafik, arphaman, abidh, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D74607
2020-02-04Fix after c25938dAdrian McCarthy1-72/+62
My refactor caused some changes in error reporting that TestAddDsymCommand.py was checking, so this restores some of the changes to preserve the old behavior and to un-xfail the affected test. Differential Revision: https://reviews.llvm.org/D74001
2020-02-03Improve help text for (lldb) target symbols addAdrian McCarthy1-5/+6
There were some missing words and awkward syntax. I think this is clearer. Differential Revision: https://reviews.llvm.org/D73589
2020-02-03Refactor CommandObjectTargetSymbolsAdd::AddModuleSymbolsAdrian McCarthy1-90/+93
* [NFC] Renamed local `matching_module_list` to `matching_modules` for conciseness. * [NFC] Eliminated redundant local variable `num_matches` to reduce the risk that changes get it out of sync with `matching_modules.GetSize()`. * Used an early return from case where the symbol file specified matches multiple modules. This is a slight behavior change, but it's an improvement: It didn't make sense to tell the user that the symbol file simultaneously matched multiple modules and no modules. * [NFC] Used an early return from the case where no matches are found, to better align with LLVM coding style. * [NFC] Simplified call of `AppendWarningWithFormat("%s", stuff)` to `AppendWarning(stuff)`. I don't think this adds any copies. It does construct a StringRef, but it was going to have to scan the string for the length anyway. * [NFC] Removed unnecessary comments and reworded others for clarity. * Used an early return if the symbol file could not be loaded. This is a behavior change because previously it could fail silently. * Used an early return if the object file could not be retrieved from the symbol file. Again, this is a change because now there's an error message. * [NFC] Eliminated a namespace alias that wasn't particularly helpful. Differential Revision: https://reviews.llvm.org/D73594
2020-01-28Make llvm::StringRef to std::string conversions explicit.Benjamin Kramer1-14/+14
This is how it should've been and brings it more in line with std::string_view. There should be no functional change here. This is mostly mechanical from a custom clang-tidy check, with a lot of manual fixups. It uncovers a lot of minor inefficiencies. This doesn't actually modify StringRef yet, I'll do that in a follow-up.
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann1-1/+1
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2020-01-14[lldb/CommandInterpreter] Remove flag that's always true (NFC)Jonas Devlieghere1-6/+2
The 'asynchronously' argument to both GetLLDBCommandsFromIOHandler and GetPythonCommandsFromIOHandler is true for all call sites. This commit simplifies the API by dropping it and giving the baton a default argument.
2019-12-16[lldb][NFC] Remove unnecessary includes in source/CommandsRaphael Isemann1-2/+0
Summary: This removes most of unnecessary includes in the `source/Commands` directory. This was generated by IWYU and a script that fixed all the bogus reports from IWYU. Patch is tested on Linux and macOS. Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: krytarowski, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D71489
2019-12-06[lldb][NFC] Migrate FileSpec::Dump to raw_ostreamRaphael Isemann1-1/+1
2019-12-04[lldb][NFC] Migrate to raw_ostream in ArchSpec::DumpTripleRaphael Isemann1-2/+2
Reviewers: labath, davide Reviewed By: davide Subscribers: clayborg, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70979
2019-11-29[lldb] Remove FileSpec->CompileUnit inheritancePavel Labath1-9/+8
Summary: CompileUnit is a complicated class. Having it be implicitly convertible to a FileSpec makes reasoning about it even harder. This patch replaces the inheritance by a simple member and an accessor function. This avoid the need for casting in places where one needed to force a CompileUnit to be treated as a FileSpec, and does not add much verbosity elsewhere. It also fixes a bug where we were wrongly comparing CompileUnit& and a CompileUnit*, which compiled due to a combination of this inheritance and the FileSpec*->FileSpec implicit constructor. Reviewers: teemperor, JDevlieghere, jdoerfert Subscribers: lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70827
2019-11-25[lldb][NFC] Allow range-based for-loops on VariableListRaphael Isemann1-23/+20
Summary: Adds support for doing range-based for-loops on LLDB's VariableList and modernises all the index-based for-loops in LLDB where possible. Reviewers: labath, jdoerfert Reviewed By: labath Subscribers: JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70668
2019-11-21[NFC] Refactor and improve comments in CommandObjectTargetAdrian McCarthy1-145/+141
Made small improvements while debugging through CommandObjectTarget::AddModuleSymbols. 1. Refactored error case for an early out, reducing the indentation of the rest of this long function. 2. Clarified some comments by correcting spelling and punctuation. 3. Reduced duplicate code at the end of the function. Tested with `ninja check-lldb` Differential Review: https://reviews.llvm.org/D70458
2019-11-07[lldb] Add -m option to 'target modules dump symtab' to disable demanglingRaphael Isemann1-4/+15
Summary: This option was added downstream in swift-lldb. This upstreams this option as it seems useful and also adds the missing tests. Reviewers: #lldb, kwk, labath Reviewed By: kwk, labath Subscribers: labath, kwk, abidh, JDevlieghere, lldb-commits Tags: #lldb, #upstreaming_lldb_s_downstream_patches Differential Revision: https://reviews.llvm.org/D69944
2019-10-31Upstream diff from swift-lldb.Adrian Prantl1-1/+1
This is very likely untested, but it looks like an obviously correct change.