Revision tags: llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2 |
|
#
089227fe |
| 11-Oct-2024 |
Adrian Prantl <aprantl@apple.com> |
Support inline diagnostics in CommandReturnObject (#110901)
and implement them for dwim-print (a.k.a. `p`) as an example.
The next step will be to expose them as structured data in
SBCommandRetu
Support inline diagnostics in CommandReturnObject (#110901)
and implement them for dwim-print (a.k.a. `p`) as an example.
The next step will be to expose them as structured data in
SBCommandReturnObject.
show more ...
|
Revision tags: llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
a0dd90eb |
| 05-Sep-2024 |
Adrian Prantl <aprantl@apple.com> |
[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)
…ror() [NFC]
|
Revision tags: llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2 |
|
#
8398ad9c |
| 31-Jul-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Unify the way we get the Target in CommandObject (#101208)
Currently, CommandObjects are obtaining a target in a variety of ways.
Often the command incorrectly operates on the selected targe
[lldb] Unify the way we get the Target in CommandObject (#101208)
Currently, CommandObjects are obtaining a target in a variety of ways.
Often the command incorrectly operates on the selected target. As an
example, when a breakpoint command is running, the current target is
passed into the command but the target that hit the breakpoint is not
the selected target. In other places we use the CommandObject's
execution context, which is frozen during the execution of the command,
and comes with its own limitations. Finally, we often want to fall back
to the dummy target if no real target is available.
Instead of having to guess how to get the target, this patch introduces
one helper function in CommandObject to get the most relevant target. In
order of priority, that's the target from the command object's execution
context, from the interpreter's execution context, the selected target
or the dummy target.
rdar://110846511
show more ...
|
Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1 |
|
#
2d704f4b |
| 27-Feb-2024 |
jimingham <jingham@apple.com> |
Start to clean up the process of defining command arguments. (#83097)
Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sen
Start to clean up the process of defining command arguments. (#83097)
Partly, there's just a lot of unnecessary boiler plate. It's also
possible to define combinations of arguments that make no sense (e.g.
eArgRepeatPlus followed by eArgRepeatPlain...) but these are never
checked since we just push_back directly into the argument definitions.
This commit is step 1 of this cleanup - do the obvious stuff. In it, all
the simple homogenous argument lists and the breakpoint/watchpoint
ID/Range types, are set with common functions. This is an NFC change, it
just centralizes boiler plate. There's no checking yet because you can't
get a single argument wrong.
The end goal is that all argument definition goes through functions and
m_arguments is hidden so that you can't define inconsistent argument
sets.
show more ...
|
Revision tags: llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3 |
|
#
563ef306 |
| 20-Feb-2024 |
jimingham <jingham@apple.com> |
Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)
This is a follow-on to:
https://github.com/llvm/llvm-project/pull/82085
The completer for register names was miss
Add the RegisterCompleter to eArgTypeRegisterName in g_argument_table (#82428)
This is a follow-on to:
https://github.com/llvm/llvm-project/pull/82085
The completer for register names was missing from the argument table. I
somehow missed that the only register completer test was x86_64, so that
test broke.
I added the completer in to the right slot in the argument table, and
added a small completions test that just uses the alias register names.
If we end up having a platform that doesn't define register names, we'll
have to skip this test there, but it should add a sniff test for
register completion that will run most everywhere.
show more ...
|
#
9ed8b272 |
| 20-Feb-2024 |
Shubham Sandeep Rastogi <srastogi22@apple.com> |
Revert "Centralize the handling of completion for simple argument lists. (#82085)"
This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.
Reverted because of greendragon failure:
**********
Revert "Centralize the handling of completion for simple argument lists. (#82085)"
This reverts commit 21631494b068d9364b8dc8f18e59adee9131a0a5.
Reverted because of greendragon failure:
******************** TEST 'lldb-api :: functionalities/completion/TestCompletion.py' FAILED ******************** Script:
show more ...
|
#
21631494 |
| 20-Feb-2024 |
jimingham <jingham@apple.com> |
Centralize the handling of completion for simple argument lists. (#82085)
Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In man
Centralize the handling of completion for simple argument lists. (#82085)
Most commands were adding argument completion handling by themselves,
resulting in a lot of unnecessary boilerplate. In many cases, this could
be done generically given the argument definition and the entries in the
g_argument_table.
I'm going to address this in a couple passes. In this first pass, I
added handling of commands that have only one argument list, with one
argument type, either single or repeated, and changed all the commands
that are of this sort (and don't have other bits of business in their
completers.)
I also added some missing connections between arg types and completions
to the table, and added a RemoteFilename and RemotePath to use in places
where we were using the Remote completers. Those arguments used to say
they were "files" but they were in fact remote files.
I also added a module arg type to use where we were using the module
completer. In that case, we should call the argument module.
show more ...
|
#
a69ecb24 |
| 13-Feb-2024 |
jimingham <jingham@apple.com> |
Add the ability to define a Python based command that uses CommandObjectParsed (#70734)
This allows you to specify options and arguments and their definitions
and then have lldb handle the completi
Add the ability to define a Python based command that uses CommandObjectParsed (#70734)
This allows you to specify options and arguments and their definitions
and then have lldb handle the completions, help, etc. in the same way
that lldb does for its parsed commands internally.
This feature has some design considerations as well as the code, so I've
also set up an RFC, but I did this one first and will put the RFC
address in here once I've pushed it...
Note, the lldb "ParsedCommand interface" doesn't actually do all the
work that it should. For instance, saying the type of an option that has
a completer doesn't automatically hook up the completer, and ditto for
argument values. We also do almost no work to verify that the arguments
match their definition, or do auto-completion for them. This patch
allows you to make a command that's bug-for-bug compatible with built-in
ones, but I didn't want to stall it on getting the auto-command checking
to work all the way correctly.
As an overall design note, my primary goal here was to make an interface
that worked well in the script language. For that I needed, for
instance, to have a property-based way to get all the option values that
were specified. It was much more convenient to do that by making a
fairly bare-bones C interface to define the options and arguments of a
command, and set their values, and then wrap that in a Python class
(installed along with the other bits of the lldb python module) which
you can then derive from to make your new command. This approach will
also make it easier to experiment.
See the file test_commands.py in the test case for examples of how this
works.
show more ...
|
Revision tags: llvmorg-18.1.0-rc2 |
|
#
76706090 |
| 05-Feb-2024 |
jeffreytan81 <jeffreytan@meta.com> |
Add commands frequency to statistics dump (#80375)
Adding command interpreter statistics into "statistics dump" command so
that we can track the command usage frequency for telemetry purpose.
This
Add commands frequency to statistics dump (#80375)
Adding command interpreter statistics into "statistics dump" command so
that we can track the command usage frequency for telemetry purpose.
This is useful to answer questions like what is the most frequently used
lldb commands across all our users.
---------
Co-authored-by: jeffreytan81 <jeffreytan@fb.com>
show more ...
|
Revision tags: llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
463a02bc |
| 25-Oct-2023 |
Pete Lawrence <plawrence@apple.com> |
[lldb] Part 1 of 2 - Refactor `CommandObject::Execute(...)` return `void` (not `bool`) (#69989)
[lldb] Part 1 of 2 - Refactor `CommandObject::Execute(...)` to return
`void` instead of ~~`bool`~~
[lldb] Part 1 of 2 - Refactor `CommandObject::Execute(...)` return `void` (not `bool`) (#69989)
[lldb] Part 1 of 2 - Refactor `CommandObject::Execute(...)` to return
`void` instead of ~~`bool`~~
Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
- A more precise status
- The error code(s) that apply to that status
Part 2 refactors the `CommandObject::DoExecute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69991](https://github.com/llvm/llvm-project/pull/69991)
rdar://117378957
show more ...
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
917b3a7e |
| 05-May-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Move Core/FileSpecList -> Utility/FileSpecList (NFC)
There's no reason for FileSpecList to live in lldb/Core while FileSpec lives in lldb/Utility. Move FileSpecList next to FileSpec.
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1 |
|
#
75ca15fc |
| 24-Mar-2023 |
Jim Ingham <jingham@apple.com> |
Fix backtick handling in parsed commands.
https://reviews.llvm.org/D146779
|
Revision tags: llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1 |
|
#
f3d0bda5 |
| 14-Sep-2022 |
Jim Ingham <jingham@apple.com> |
Revert "Revert "Be more careful to maintain quoting information when parsing commands.""
This reverts commit ac05bc0524c66c74278b26742896a4c634c034cf.
I had incorrectly removed one set of check
Revert "Revert "Be more careful to maintain quoting information when parsing commands.""
This reverts commit ac05bc0524c66c74278b26742896a4c634c034cf.
I had incorrectly removed one set of checks in the option handling in Options::ParseAlias because I couldn't see what it is for. It was a bit obscure, but it handled the case where you pass "-something=other --" as the input_line, which caused the built-in "run" alias not to return the right value for IsDashDashCommand, causing TestHelp.py to fail.
show more ...
|
#
ac05bc05 |
| 13-Sep-2022 |
Jim Ingham <jingham@apple.com> |
Revert "Be more careful to maintain quoting information when parsing commands."
This reverts commit 6c089b2af5d8d98f66b27b67f70958f520820a76.
This was causing the test test_help_run_hides_options f
Revert "Be more careful to maintain quoting information when parsing commands."
This reverts commit 6c089b2af5d8d98f66b27b67f70958f520820a76.
This was causing the test test_help_run_hides_options from TestHelp.py to fail on Linux and Windows (but the test succeeds on macOS). The decision to print option information is determined by CommandObjectAlias::IsDashDashCommand which was changed, but only by replacing an inline string constant with a const char * CommandInterpreter::g_argument which has the same string value. I can't see why this would fail, I'll have to spin up a vm to see if I can repo there.
show more ...
|
Revision tags: llvmorg-15.0.0 |
|
#
6c089b2a |
| 31-Aug-2022 |
Jim Ingham <jingham@apple.com> |
Be more careful to maintain quoting information when parsing commands.
This is particularly a problem for alias construction, where you might want to have a backtick surrounded option in the alias.
Be more careful to maintain quoting information when parsing commands.
This is particularly a problem for alias construction, where you might want to have a backtick surrounded option in the alias. Before this patch:
command alias expression -Z \`argc\` -- argv
for instance would be rendered as:
expression -Z argc -- argv
and would fail to work.
Differential Revision: https://reviews.llvm.org/D133045
show more ...
|
Revision tags: llvmorg-15.0.0-rc3 |
|
#
b6d56dda |
| 22-Aug-2022 |
Zequan Wu <zequanwu@google.com> |
[LLDB] Clean up after command fails
`CommandObject::CheckRequirements()` requires m_exe_ctx being cleaned up.
Differential Revision: https://reviews.llvm.org/D132397
|
Revision tags: llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
bcae3cdb |
| 15-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Print the enum values and their description in the help output
Print the enum values and their description in the help output for argument values. Until now, there was no way to get these val
[lldb] Print the enum values and their description in the help output
Print the enum values and their description in the help output for argument values. Until now, there was no way to get these values and their description.
Example output:
(lldb) help <description-verbosity> <description-verbosity> -- How verbose the output of 'po' should be.
compact : Only show the description string full : Show the full output, including persistent variable's name and type
Differential revision: https://reviews.llvm.org/D129707
show more ...
|
#
7ced9fff |
| 14-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Refactor command option enum values (NFC)
Refactor the command option enum values and the command argument table to connect the two. This has two benefits:
- We guarantee that two options t
[lldb] Refactor command option enum values (NFC)
Refactor the command option enum values and the command argument table to connect the two. This has two benefits:
- We guarantee that two options that use the same argument type have the same accepted values. - We can print the enum values and their description in the help output. (D129707)
Differential revision: https://reviews.llvm.org/D129703
show more ...
|
#
b620852d |
| 12-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Make the g_arguments_data constexpr and fix the static assert
This fixes the static assert that's meant to keep the g_arguments_data table in sync with the CommandArgumentType enumeration. In
[lldb] Make the g_arguments_data constexpr and fix the static assert
This fixes the static assert that's meant to keep the g_arguments_data table in sync with the CommandArgumentType enumeration. Indeed, the assert didn't fire even though the current code is missing an entry. This patches fixes that as well.
Differential revision: https://reviews.llvm.org/D129529
show more ...
|
#
c1b07d61 |
| 23-Jun-2022 |
Jim Ingham <jingham@apple.com> |
Have CommandObjectParsed check for "commands that take no arguments".
This is currently being done in an ad hoc way, and so for some commands it isn't being checked. We have the info to make this c
Have CommandObjectParsed check for "commands that take no arguments".
This is currently being done in an ad hoc way, and so for some commands it isn't being checked. We have the info to make this check, since commands are supposed to add their arguments to the m_arguments field of the CommandObject. This change uses that info to check whether the command received arguments in error.
A handful of commands weren't defining their argument types, I also had to fix them. And a bunch of commands were checking for arguments by hand, so I removed those checks in favor of the CommandObject one. That also meant I had to change some tests that were checking for the ad hoc error outputs.
Differential Revision: https://reviews.llvm.org/D128453
show more ...
|
#
be265d25 |
| 24-Jun-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Add support for specifying a log handler
This patch adds a new flag to `log enable`, allowing the user to specify a custom log handler. In addition to the default (stream) handler, this allow
[lldb] Add support for specifying a log handler
This patch adds a new flag to `log enable`, allowing the user to specify a custom log handler. In addition to the default (stream) handler, this allows using the circular log handler (which logs to a fixed size, in-memory circular buffer) as well as the system log handler (which logs to the operating system log).
Differential revision: https://reviews.llvm.org/D128323
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
#
e473e79c |
| 09-May-2022 |
David Spickett <david.spickett@linaro.org> |
[lldb][NFC] Make cmd a reference in GenerateOptionUsage
Nowhere in lldb do we call this with a null pointer. If we did, the first line of the function would fault anyway.
Reviewed By: JDevlieghere
[lldb][NFC] Make cmd a reference in GenerateOptionUsage
Nowhere in lldb do we call this with a null pointer. If we did, the first line of the function would fault anyway.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D125218
show more ...
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2 |
|
#
94038c57 |
| 26-Nov-2021 |
Venkata Ramanaiah Nalamothu <ramana.venkat83@gmail.com> |
[lldb] Fix 'memory write' to not allow specifying values when writing file contents
Currently the 'memory write' command allows specifying the values when writing the file contents to memory but the
[lldb] Fix 'memory write' to not allow specifying values when writing file contents
Currently the 'memory write' command allows specifying the values when writing the file contents to memory but the values are actually ignored. This patch fixes that by erroring out when values are specified in such cases.
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D114544
show more ...
|
Revision tags: llvmorg-13.0.1-rc1 |
|
#
c5011aed |
| 12-Oct-2021 |
Jim Ingham <jingham@apple.com> |
Add a "command container" hierarchy to allow users to add container nodes.
The point is to allow users with a related set of script based commands to organize their commands in a hierarchy in the co
Add a "command container" hierarchy to allow users to add container nodes.
The point is to allow users with a related set of script based commands to organize their commands in a hierarchy in the command set, rather than having to have only top-level commands.
Differential Revision: https://reviews.llvm.org/D110298
show more ...
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
#
e50f9c41 |
| 24-Jun-2021 |
Martin Storsjö <martin@martin.st> |
[lldb] Rename StringRef _lower() method calls to _insensitive()
|