Use value instead of getValue (NFC)

[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 ...

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 ...

[lld] Don't use Optional::hasValue (NFC)

This patch replaces x.hasValue() with x where x is contextually
convertible to bool.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

Don't use Optional::hasValue (NFC)

[lldb] Use value_or instead of getValueOr (NFC)

[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 ...

[lldb] Add setting for max depth of value object printing (NFC)

This adds a setting (`target.max-children-depth`) that will provide a default value for the `--depth` flag used by `expression` and `f

[lldb] Add setting for max depth of value object printing (NFC)

This adds a setting (`target.max-children-depth`) that will provide a default value for the `--depth` flag used by `expression` and `frame variable`.

The new setting uses the same default that's currently fixed in source: `UINT32_MAX`.

This provides two purposes:

1. Allowing downstream forks to provide a customized default.
2. Allowing users to set their own default.

Following `target.max-children-count`, a warning is emitted when the max depth is reached. The warning lets users know which flags or settings they can customize. This warning is shown only when the limit is the default value.

rdar://87466495

Differential Revision: https://reviews.llvm.org/D123954

show more ...

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Dif

[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB

Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844

show more ...

[Commands] Remove redundant member initialization (NFC)

Identified with readability-redundant-member-init.

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, ev

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.

This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.

Differential Revision: https://reviews.llvm.org/D116788

Recommitting after D116901 and D116863.

(cherry picked from commit 2c7d10c41278181e3e45c68f28b501cd95193a8a)

show more ...

Revert "[lldb] Set result error state in 'frame variable'"

This reverts commit 2bcff220bf1e372e91491911fe0bb76c4c4bbef8.

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, ev

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.

This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.

Differential Revision: https://reviews.llvm.org/D116788

(cherry picked from commit 2c7d10c41278181e3e45c68f28b501cd95193a8a)

show more ...

Revert "[lldb] Set result error state in 'frame variable'"

This reverts commit 2c7d10c41278181e3e45c68f28b501cd95193a8a.

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, ev

[lldb] Set result error state in 'frame variable'

Ensure that errors in `frame variable` are reflected in result object.

The statistics for `frame variable` show invocations as being successful, even
when executing one of the error paths.

This change replaces `result.GetErrorStream()` with `result.AppendError()`,
which also sets the status to `eReturnStatusFailed`.

Differential Revision: https://reviews.llvm.org/D116788

show more ...

[lldb] Break out long help for 'frame var'

The current help for `frame variable` is somewhat long. Its length, combined
with the few aliases (`var`, `v`, and `vo`) can make the output of `apropos`
r

[lldb] Break out long help for 'frame var'

The current help for `frame variable` is somewhat long. Its length, combined
with the few aliases (`var`, `v`, and `vo`) can make the output of `apropos`
redundant and noisy.

This separates out the details into a separate long help.

Differential Revision: https://reviews.llvm.org/D116708

show more ...

Modify "statistics dump" to dump JSON.

This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get st

Modify "statistics dump" to dump JSON.

This patch is a smaller version of a previous patch https://reviews.llvm.org/D110804.

This patch modifies the output of "statistics dump" to be able to get stats from the current target. It adds 3 new stats as well. The output of "statistics dump" is now emitted as JSON so that it can be used to track performance and statistics and the output could be used to populate a database that tracks performance. Sample output looks like:

(lldb) statistics dump
{
"expressionEvaluation": {
"failures": 0,
"successes": 0
},
"firstStopTime": 0.34164492800000001,
"frameVariable": {
"failures": 0,
"successes": 0
},
"launchOrAttachTime": 0.31969605400000001,
"targetCreateTime": 0.0040863039999999998
}

The top level keys are:

"expressionEvaluation" which replaces the previous stats that were emitted as plain text. This dictionary contains the success and fail counts.
"frameVariable" which replaces the previous stats for "frame variable" that were emitted as plain text. This dictionary contains the success and fail counts.
"targetCreateTime" contains the number of seconds it took to create the target and load dependent libraries (if they were enabled) and also will contain symbol preloading times if that setting is enabled.
"launchOrAttachTime" is the time it takes from when the launch/attach is initiated to when the first private stop occurs.
"firstStopTime" is the time in seconds that it takes to stop at the first stop that is presented to the user via the LLDB interface. This value will only have meaning if you set a known breakpoint or stop location in your code that you want to measure as a performance test.

This diff is also meant as a place to discuess what we want out of the "statistics dump" command before adding more funcionality. It is also meant to clean up the previous code that was storting statistics in a vector of numbers within the lldb_private::Target class.

Differential Revision: https://reviews.llvm.org/D111686

show more ...

[lldb] Fix 'frame diagnose' docstring typo

[lldb] Allow to register frame recognizers applied beyond the first instruction

It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points t

[lldb] Allow to register frame recognizers applied beyond the first instruction

It is currently possible to register a frame recognizer, but it will be applied if and only if the frame's PC points to the very first instruction of the specified function, which limits usability of this feature.

The implementation already supports changing this behaviour by passing an additional flag, but it's not possible to set it via the command interface. Fix that.

Reviewed By: jingham

Differential Revision: https://reviews.llvm.org/D108510

show more ...

[lldb] Remove redundant calls to set eReturnStatusFailed

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 AppendEr

[lldb] Remove redundant calls to set eReturnStatusFailed

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

show more ...

[lldb][NFC] Remove all uses of StringRef::withNullAsEmpty in LLDB

A long time ago LLDB wanted to start using StringRef instead of
C-Strings/ConstString but was blocked by the fact that the StringRef

[lldb][NFC] Remove all uses of StringRef::withNullAsEmpty in LLDB

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

show more ...

[lldb] move the frame index completion into a common completion and apply it to `thread backtrace -s`

Commands frame select and thread backtrace -s can be completed in the same way.
Moved the dedica

[lldb] move the frame index completion into a common completion and apply it to `thread backtrace -s`

Commands frame select and thread backtrace -s can be completed in the same way.
Moved the dedicated completion of frame select into a common completion and
apply it to the both commands, along with the test modified.

show more ...

[lldb] Make deleting frame recognizers actually work

Summary:

Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are suppos

[lldb] Make deleting frame recognizers actually work

Summary:

Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are supposed to be ignored by the
rest of the frame recognizer code. 'frame recognizer delete' is supposed to set
that flag. 'frame recognizer clear' however actually deletes all frame
recognizers (so, it doesn't set the flag but directly deletes them from the
list).

The current implementation of this concept is pretty broken. `frame recognizer
delete` sets the flag, but it somehow thinks that the recognizer id is an index
in the recognizer list. That's not true as it's actually just a member of each
recognizer entry. So it actually just sets the `deleted` flag for a random other
recognizer. The tests for the recognizer still pass as `frame recognizer list`
is also broken and just completely ignored the `deleted` flag and lists all
recognizers. Also `frame recognizer delete` just ignores if it can't actually
delete a recognizer if the id is invalid.

I think we can simplify this whole thing by just actually deleting recognizers
instead of making sure all code is actually respecting the `deleted` flag. I
assume the intention of this was to make sure that all recognizers are getting
unique ids over the course of an LLDB session, but as `clear` is actually
deleting them and we keep recycling ids, that didn't really work to begin with.

This patch deletes the `deleted` flag and just actually deletes the stored
recognizer. Also adds the missing error message in case it find a recognizer
with a given id.

Reviewers: mib

Reviewed By: mib

Subscribers: abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D84404

show more ...