[lldb] Improve formatting of dlopen error messages (NFC)

Ensure there's a space between "utility" and "function", and also makes
it easier to grep/search for "utility function".

While making this c

[lldb] Improve formatting of dlopen error messages (NFC)

Ensure there's a space between "utility" and "function", and also makes
it easier to grep/search for "utility function".

While making this change, I also re-formatted the other dlopen error messages
(with clang-format). This fix other instances of spaces missing between words,
and makes each of these strings fit a single line, making them greppable.

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

show more ...

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).

I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.

This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.

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

show more ...

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
mem

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

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

show more ...

[LLDB] Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

MakeLoadImageUtilityFunction() is not using extern "C" for external C functions
and it is not using eLanguageTy

[LLDB] Modifying expression code in MakeLoadImageUtilityFunction to be more consistent

MakeLoadImageUtilityFunction() is not using extern "C" for external C functions
and it is not using eLanguageTypeC_plus_plus. So I am modifying it to be consistent.

Also see: rdar://87544782

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

show more ...

Revert "[lldb] Remove the global platform list"

It makes module dependencies loopier.

This reverts commits 49cffe3c7fab74252d4b6a073303c803dc1659f0 and
ffb9429b6f3c29ab4687b96fd85374924c98ad16.

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main

[lldb] Remove the global platform list

This patch moves the platform creation and selection logic into the
per-debugger platform lists. I've tried to keep functional changes to a
minimum -- the main (only) observable difference in this change is that
APIs, which select a platform by name (e.g.,
Debugger::SetCurrentPlatform) will not automatically pick up a platform
associated with another debugger (or no debugger at all).

I've also added several tests for this functionality -- one of the
pleasant consequences of the debugger isolation is that it is now
possible to test the platform selection and creation logic.

This is a product of the discussion at
<https://discourse.llvm.org/t/multiple-platforms-with-the-same-name/59594>.

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

show more ...

[lldb] Fix race condition between lldb-vscode and stop hooks executor

The race is between these two pieces of code that are executed in two separate
lldb-vscode threads (the first is in the main thr

[lldb] Fix race condition between lldb-vscode and stop hooks executor

The race is between these two pieces of code that are executed in two separate
lldb-vscode threads (the first is in the main thread and another is in the
event-handling thread):

```
// lldb-vscode.cpp
g_vsc.debugger.SetAsync(false);
g_vsc.target.Launch(launch_info, error);
g_vsc.debugger.SetAsync(true);
```

```
// Target.cpp
bool old_async = debugger.GetAsyncExecution();
debugger.SetAsyncExecution(true);
debugger.GetCommandInterpreter().HandleCommands(GetCommands(), exc_ctx,
options, result);
debugger.SetAsyncExecution(old_async);
```

The sequence that leads to the bug is this one:
1. Main thread enables synchronous mode and launches the process.
2. When the process is launched, it generates the first stop event.
3. This stop event is catched by the event-handling thread and DoOnRemoval
is invoked.
4. Inside DoOnRemoval, this thread runs stop hooks. And before running stop
hooks, the current synchronization mode is stored into old_async (and
right now it is equal to "false").
5. The main thread finishes the launch and returns to lldb-vscode, the
synchronization mode is restored to asynchronous by lldb-vscode.
6. Event-handling thread finishes stop hooks processing and restores the
synchronization mode according to old_async (i.e. makes the mode synchronous)
7. And now the mode is synchronous while lldb-vscode expects it to be
asynchronous. Synchronous mode forbids the process to broadcast public stop
events, so, VS Code just hangs because lldb-vscode doesn't notify it about
stops.

So, this diff makes the target intercept the first stop event if the process is
launched in the synchronous mode, thus preventing stop hooks execution.

The bug is only present on Windows because other platforms already
intercept this event using their own hijacking listeners.

So, this diff also fixes some problems with lldb-vscode tests on Windows to make
it possible to run the related test. Other tests still can't be enabled because
the debugged program prints something into stdout and LLDB can't intercept this
output and redirect it to lldb-vscode properly.

Reviewed By: jingham

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

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

Fix error reporting for "process load" and add a test for it.

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

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where

[lldb] Return StringRef from PluginInterface::GetPluginName

There is no reason why this function should be returning a ConstString.

While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.

I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.

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

show more ...

[lldb] Make Platform::DebugProcess take a Target reference

instead of a pointer. There are just two callers of this function, and
both of them have a valid target pointer, so there's no need for all

[lldb] Make Platform::DebugProcess take a Target reference

instead of a pointer. There are just two callers of this function, and
both of them have a valid target pointer, so there's no need for all
implementations to concern themselves with whether the pointer is null.

show more ...

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

Modify OpenOptions enum to open the future path into synchronizing
vFile:open bits with GDB. Currently, LLDB and GDB use different

[lldb] [gdb-remote] Add eOpenOptionReadWrite for future gdb compat

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

show more ...

[lldb] Replace default bodies of special member functions with = default;

Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo

[lldb] Replace default bodies of special member functions with = default;

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

show more ...

[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY (reapply)

In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulti

[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY (reapply)

In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.

This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).

This was previously committed as cb8c1ee269da and reverted due to
unknown failures on the Linux bots. This version adds additional asserts
to check that the shared objects are where we expect them & that calling
f1() from libt1 produces the expected value. The Linux failure is
tracked by https://bugs.llvm.org/show_bug.cgi?id=49656.

See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html

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

show more ...

Revert "[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY"

This reverts commit cb8c1ee269da72eb6e2c18800cd8ab0a74050785. The test
is failing on Debian for unknown reasons.

https://lab.llvm

Revert "[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY"

This reverts commit cb8c1ee269da72eb6e2c18800cd8ab0a74050785. The test
is failing on Debian for unknown reasons.

https://lab.llvm.org/buildbot/#/builders/68/builds/8990

show more ...

[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY

In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to bein

[lldb/PlatformPOSIX] Change LoadImage default to RTLD_LAZY

In general, it seems like the debugger should allow programs to load & run with
libraries as far as possible, instead of defaulting to being super-picky about
unavailable symbols.

This is critical on macOS/Darwin, as libswiftCore.dylib may 1) export a version
symbol using @available markup and then 2) expect that other exported APIs are
only dynamically used once the version symbol is checked. We can't open a
version of the library built with a bleeding-edge SDK on an older OS without
RTLD_LAXY (or pervasive/expensive @available markup added to dyld APIs).

See: https://lists.llvm.org/pipermail/lldb-dev/2021-March/016796.html

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

show more ...

[lldb] Move PlatformPOSIX::ConnectToWaitingProcesses to RemoteAwarePlatform

The functionality is not posix specific. Also force the usage of the
gdb-remote process plugin in the gdb platform class.

[lldb] Move PlatformPOSIX::ConnectToWaitingProcesses to RemoteAwarePlatform

The functionality is not posix specific. Also force the usage of the
gdb-remote process plugin in the gdb platform class.

This is not sufficient to make TestPlatformConnect pass on windows (it
seems it suffers from module loading issues, unrelated to this test),
but it at least makes it shut down correctly, so I change the skip to an
xfail.

show more ...

Make the error condition in Value::ValueType explicit (NFC)

The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduce

Make the error condition in Value::ValueType explicit (NFC)

The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537

show more ...

[lldb] "target create" shouldn't save target if the command failed

TargetList::CreateTarget automatically adds created target to the list, however,
CommandObjectTargetCreate does some additional pre

[lldb] "target create" shouldn't save target if the command failed

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

show more ...

[lldb] [Platform/POSIX] Use gdb-remote plugin when attaching

Force gdb-remote plugin when attaching using the derivatives
of PlatformPOSIX class. This is consistent with the behavior
for launching

[lldb] [Platform/POSIX] Use gdb-remote plugin when attaching

Force gdb-remote plugin when attaching using the derivatives
of PlatformPOSIX class. This is consistent with the behavior
for launching processes (via DebugProcess() method) and guarantees
consistent plugin choice on FreeBSD.

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

show more ...

[lldb][NFC] Rename TypeSystemClang::GetScratch to ScratchTypeSystemClang::GetForTarget

Also add some documentation while I'm at it.

[lldb] Prevent 'process connect' from using local-only plugins

Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections. T

[lldb] Prevent 'process connect' from using local-only plugins

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

show more ...

[lldb] Redesign Target::GetUtilityFunctionForLanguage API

This patch redesigns the Target::GetUtilityFunctionForLanguage API:

- Use a unique_ptr instead of a raw pointer for the return type.
- Wr

[lldb] Redesign Target::GetUtilityFunctionForLanguage API

This patch redesigns the Target::GetUtilityFunctionForLanguage API:

- Use a unique_ptr instead of a raw pointer for the return type.
- Wrap the result in an llvm::Expected instead of using a Status object as an I/O parameter.
- Combine the action of "getting" and "installing" the UtilityFunction as they always get called together.
- Pass std::strings instead of const char* and std::move them where appropriate.

There's more room for improvement but I think this tackles the most
prevalent issues with the current API.

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

show more ...

[lldb] [Platform] Move common ::DebugProcess() to PlatformPOSIX

Move common ::DebugProcess() implementation shared by Linux and NetBSD
(and to be shared by FreeBSD shortly) into PlatformPOSIX, and m

[lldb] [Platform] Move common ::DebugProcess() to PlatformPOSIX

Move common ::DebugProcess() implementation shared by Linux and NetBSD
(and to be shared by FreeBSD shortly) into PlatformPOSIX, and move
the old base implementation used only by Darwin to PlatformDarwin.

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

show more ...