Don't use Optional::hasValue (NFC)

[lldb] Fix spurious assertion in PrintCommandOutput

When the string passed to PrintCommandOutput doesn't end with a newline,
`written` will exceed `size` and result in an lldbassert.

After 8e776bb6

[lldb] Fix spurious assertion in PrintCommandOutput

When the string passed to PrintCommandOutput doesn't end with a newline,
`written` will exceed `size` and result in an lldbassert.

After 8e776bb660dda6c51ce7ca6cea641db1f47aa9cf we don't really need
written anymore and we can check whether `str` is empty instead. This
patch simplifies the code and removes the assert that's no longer
relevant.

Differential revision: https://reviews.llvm.org/D126081

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

Don't push null ExecutionContext on CommandInterp exectx stack

The driver can push a null ExecutionContext on to this stack,
and later calls to SBCommandInterpreter::HandleCommand which
don't specif

Don't push null ExecutionContext on CommandInterp exectx stack

The driver can push a null ExecutionContext on to this stack,
and later calls to SBCommandInterpreter::HandleCommand which
don't specify an ExecutionContext can pull an entry from the
stack, resulting in settings that aren't applied.

Differential Revision: https://reviews.llvm.org/D111209
rdar://81489207

show more ...

Fix a mistyping introduced with the new container command.

I also added a call to help in the test which was crashing before
the test, and not after.

Add a setting to not require --overwrite to overwrite commands.

Protecting against accidental overwriting of commands is good, but
having to pass a flag to overwrite the command when developing your

Add a setting to not require --overwrite to overwrite commands.

Protecting against accidental overwriting of commands is good, but
having to pass a flag to overwrite the command when developing your
commands is pretty annoying. This adds a setting to defeat the protection
so you can do this once at the start of your session and not have to
worry about it again.

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

show more ...

[lldb] Remove lldbassert from CommandInterpreter::PrintCommandOutput

The assertion checks that the command output doesn't contain any null
bytes. I'm not sure if the intention was to make sure the s

[lldb] Remove lldbassert from CommandInterpreter::PrintCommandOutput

The assertion checks that the command output doesn't contain any null
bytes. I'm not sure if the intention was to make sure the string wasn't
shorter than the reported length or if this was a way to catch us
accidentally writing an (unformatted) null byte.

The consensus is that we don't want to have embedded nulls in the
command output, but that this isn't the right place to enforce that.

Differential revision: https://reviews.llvm.org/D122025

show more ...

Re-land "[lldb] Synchronize output through the IOHandler"

Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.

A scenario where

Re-land "[lldb] Synchronize output through the IOHandler"

Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.

A scenario where this could happen is when a thread (the default event
thread for example) is using the debugger's asynchronous stream. We
would delegate this operation to the IOHandler which might be running on
another thread. Until this patch there was nothing to synchronize the
two at the IOHandler level.

Differential revision: https://reviews.llvm.org/D121500

show more ...

Revert "[lldb] Synchronize output through the IOHandler"

This reverts commit 242c574dc03e4b90e992cc8d07436efc3954727f because it
breaks the following tests on the bots:

- TestGuiExpandThreadsTree.

Revert "[lldb] Synchronize output through the IOHandler"

This reverts commit 242c574dc03e4b90e992cc8d07436efc3954727f because it
breaks the following tests on the bots:

- TestGuiExpandThreadsTree.py
- TestBreakpointCallbackCommandSource.py

show more ...

[lldb] Synchronize output through the IOHandler

Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.

A scenario where this could

[lldb] Synchronize output through the IOHandler

Add synchronization to the IOHandler to prevent multiple threads from
writing concurrently to the output or error stream.

A scenario where this could happen is when a thread (the default event
thread for example) is using the debugger's asynchronous stream. We
would delegate this operation to the IOHandler which might be running on
another thread. Until this patch there was nothing to synchronize the
two at the IOHandler level.

Differential revision: https://reviews.llvm.org/D121500

show more ...

[LLDB] Flush stream at the end of PrintCommandOutput

On Windows, lldb doesn't print any error message until exit. This fixes it.

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

[lldb] Fix check for TARGET_OS_IPHONE

Instead of checking whether TARGET_OS_IPHONE is set to 1, the current
code just check the existence of TARGET_OS_IPHONE, which either always
succeeds or always

[lldb] Fix check for TARGET_OS_IPHONE

Instead of checking whether TARGET_OS_IPHONE is set to 1, the current
code just check the existence of TARGET_OS_IPHONE, which either always
succeeds or always fails, depending on whether you have
TargetConditionals.h included.

show more ...

[lldb] Add support for a "global" lldbinit file

This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a pa

[lldb] Add support for a "global" lldbinit file

This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a particular user), or the cwd lldbinit file (useful for
project-specific settings), this file can be used to customize an entire
lldb installation to a particular environment.

The feature is enabled at build time, by setting the
LLDB_GLOBAL_INIT_DIRECTORY variable to a path to a directory which
should contain an "lldbinit" file. Lldb will then load the file at
startup, if it exists, and if automatic init loading has not been
disabled. Relative paths will be resolved (at runtime) relative to the
location of the lldb library (liblldb or LLDB.framework).

The system-wide lldbinit file will be loaded first, before any
$HOME/.lldbinit and $CWD/.lldbinit files are processed, so that those
can override any system-wide settings.

More information can be found on the RFC thread at
<https://discourse.llvm.org/t/rfc-system-wide-lldbinit/59933>.

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

show more ...

[lldb/API] Add a way to check if the CommandInterpreter is interactive

This patch adds the ability for the user to check if the command
interpreter's IOHandler is interactive.

Differential Revision

[lldb/API] Add a way to check if the CommandInterpreter is interactive

This patch adds the ability for the user to check if the command
interpreter's IOHandler is interactive.

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

Signed-off-by: Med Ismail Bennani <[email protected]>

show more ...

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the

Add a repeat command option for "thread backtrace --count N".

This way if you have a long stack, you can issue "thread backtrace --count 10"
and then subsequent <Return>-s will page you through the stack.

This took a little more effort than just adding the repeat command, since
the GetRepeatCommand API was returning a "const char *". That meant the command
had to keep the repeat string alive, which is inconvenient. The original
API returned either a nullptr, or a const char *, so I changed the private API to
return an llvm::Optional<std::string>. Most of the patch is propagating that change.

Also, there was a little thinko in fetching the repeat command. We don't
fetch repeat commands for commands that aren't being added to history, which
is in general reasonable. And we don't add repeat commands to the history -
also reasonable. But we do want the repeat command to be able to generate
the NEXT repeat command. So I adjusted the logic in HandleCommand to work
that way.

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

show more ...

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
inf

[lldb] Rename Logging.h to LLDBLog.h and clean up includes

Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.

show more ...

[lldb] Convert "LLDB" log channel to the new API

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

[lldb] Compute fully qualified command names in FindCommandsForApropos

Fixes incomplete command names in `apropos` results.

The full command names given by `apropos` have come from command name str

[lldb] Compute fully qualified command names in FindCommandsForApropos

Fixes incomplete command names in `apropos` results.

The full command names given by `apropos` have come from command name string
literals given to `CommandObject` constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
`apropos` output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.

There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the `language objc` subcommand
has to set its command name string to "objc", which results in apropos printing
results as `objc ...` instead of `language objc ...`.

To fix both of these issues, this commit changes `FindCommandsForApropos` to
derive the fully qualified command name using the keys of subcommand maps.

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

(cherry picked from commit b3bfd595a548cd85b12e4e83729436cb73b26f29)

show more ...

Revert "[lldb] Compute fully qualified command names in FindCommandsForApropos"

This reverts commit b3bfd595a548cd85b12e4e83729436cb73b26f29.

[lldb] Compute fully qualified command names in FindCommandsForApropos

Fixes incomplete command names in `apropos` results.

The full command names given by `apropos` have come from command name str

[lldb] Compute fully qualified command names in FindCommandsForApropos

Fixes incomplete command names in `apropos` results.

The full command names given by `apropos` have come from command name string
literals given to `CommandObject` constructors. For most commands, this has
been accurate, but some commands have incorrect strings. This results in
`apropos` output that doesn't tell the user the full command name they might
want learn more about. These strings can be fixed.

There's a seperate issue that can't be fixed as easily: plugin commands. With
the way they're implemented, plugin commands have to exclude the root command
from their command name string. To illustrate, the `language objc` subcommand
has to set its command name string to "objc", which results in apropos printing
results as `objc ...` instead of `language objc ...`.

To fix both of these issues, this commit changes `FindCommandsForApropos` to
derive the fully qualified command name using the keys of subcommand maps.

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

show more ...

[lldb] Create a property to store the REPL language

Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.G

[lldb] Create a property to store the REPL language

Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.

Differential revision: https://reviews.llvm.org/D116697

show more ...

Remove redundant return and continue statements (NFC)

Identified with readability-redundant-control-flow.

Revert "[lldb] Load the fblldb module automatically"

This reverts commit 2e6a0a8b81d7be948491ce39d241695dc1385429.

It was pushed by mistake..