Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke

Revert "[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute." and follow-ups

This reverts commit 9429b67b8e300e638d7828bbcb95585f85c4df4d.

It broke the build on Windows, see comments on https://reviews.llvm.org/D130309

It also reverts these follow-ups:

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit f959d815f4637890ebbacca379f1c38ab47e4e14.

Revert "Fix buildbot breakage after https://reviews.llvm.org/D130309."
This reverts commit 0bbce7a4c2d2bff622bdadd4323f93f5d90e6d24.

Revert "Cache the value for absolute path in FileSpec."
This reverts commit dabe877248b85b34878e75d5510339325ee087d0.

show more ...

Use the range-based overload of llvm::sort where possible

Reviewed By: MaskRay

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

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const ref

[NFC] Improve FileSpec internal APIs and usage in preparation for adding caching of resolved/absolute.

The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.

Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;

This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.

The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.

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

show more ...

[lldb] Add a setting to specify the preferred dynamic class info extractor o

Add a setting to configure how LLDB parses dynamic Objective-C class
metadata. By default LLDB will choose the most appro

[lldb] Add a setting to specify the preferred dynamic class info extractor o

Add a setting to configure how LLDB parses dynamic Objective-C class
metadata. By default LLDB will choose the most appropriate method for
the target OS.

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

show more ...

[lldb] Silence a GCC warning about missing returns after a fully covered switch. NFC.

Store a by name list of signals with their actions in the Target
so that they can be used to prime new Process runs. "process handle"
was also changed to populate the dummy target if there's no sele

Store a by name list of signals with their actions in the Target
so that they can be used to prime new Process runs. "process handle"
was also changed to populate the dummy target if there's no selected
target, so that the settings will get copied into new targets.

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

show more ...

[lldb] Remove non-address bits from read/write addresses in lldb

Non-address bits are not part of the virtual address in a pointer.
So they must be removed before passing to interfaces like ptrace.

[lldb] Remove non-address bits from read/write addresses in lldb

Non-address bits are not part of the virtual address in a pointer.
So they must be removed before passing to interfaces like ptrace.

Some of them we get way with not removing, like AArch64's top byte.
However this is only because of a hardware feature that ignores them.

This change updates all the Process/Target Read/Write memory methods
to remove non-address bits before using addresses.

Doing it in this way keeps lldb-server simple and also fixes the
memory caching when differently tagged pointers for the same location
are read.

Removing the bits is done at the ReadMemory level not DoReadMemory
because particualrly for process, many subclasses override DoReadMemory.

Tests have been added for read/write at the command and API level,
for process and target. This includes variants like
Read<sometype>FromMemory. Commands are tested to make sure we remove
at the command and API level.

"memory find" is not included because:
* There is no API for it.
* It already has its own address handling tests.

Software breakpoints do use these methods but they are not tested
here because there are bigger issues to fix with those. This will
happen in another change.

Reviewed By: omjavaid

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

show more ...

Revert "[lldb] parallelize calling of Module::PreloadSymbols()"

This reverts commit b7d807dbcff0d9df466e0312b4fef57178d207be -- it
breaks TestMultipleDebuggers.py.

[lldb] parallelize calling of Module::PreloadSymbols()

If LLDB index cache is enabled and everything is cached, then loading of debug
info is essentially single-threaded, because it's done from Prel

[lldb] parallelize calling of Module::PreloadSymbols()

If LLDB index cache is enabled and everything is cached, then loading of debug
info is essentially single-threaded, because it's done from PreloadSymbols()
called from GetOrCreateModule(), which is called from a loop calling
LoadModuleAtAddress() in DynamicLoaderPOSIXDYLD. Parallelizing the entire
loop could be unsafe because of GetOrCreateModule() operating on a module
list, so instead move only the PreloadSymbols() call to Target::ModulesDidLoad()
and parallelize there, which should be safe.

This may greatly reduce the load time if the debugged program uses a large
number of binaries (as opposed to monolithic programs where this presumably
doesn't make a difference). In my specific case of LibreOffice Calc this reduces
startup time from 6s to 2s.

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

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

[trace] clear any existing tracing sessions before relaunching the binary

There's a bug caused when a process is relaunched: the target, which
doesn't change, keeps the Trace object from the previou

[trace] clear any existing tracing sessions before relaunching the binary

There's a bug caused when a process is relaunched: the target, which
doesn't change, keeps the Trace object from the previous process, which
is already defunct, and causes segmentation faults when it's attempted
to be used.
A fix is to clean up the Trace object when the target is disposing of
the previous process during relaunches.

A way to reproduce this:
```
lldb a.out
b main
r
process trace start
c
r
process trace start
```

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

show more ...

[lldb] Update TargetProperties::CheckJITObjectsDir to use ReportError

Don't report memory return values on MacOS_arm64 of SysV_arm64 ABI's.

They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is corre

Don't report memory return values on MacOS_arm64 of SysV_arm64 ABI's.

They don't require that the memory return address be restored prior to
function exit, so there's no guarantee the value is correct. It's better
to return nothing that something that's not accurate.

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

show more ...

[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platfo

[lldb] Plumb process host architecture through platform selection

To allow us to select a different platform based on where the process is
running, plumb the process host architecture through platform selection.

This patch is in preparation for D121444 which needs this functionality
to tell apart iOS binaries running on Apple Silicon vs on a remote iOS
device.

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

show more ...

[lldb] Removed scoped timer from ReadMemoryFromFileCache

`ReadMemoryFromFileCache` can be called at a high rate, and has fast execution.
Signposts for high rate & brief duration can have a negative

[lldb] Removed scoped timer from ReadMemoryFromFileCache

`ReadMemoryFromFileCache` can be called at a high rate, and has fast execution.
Signposts for high rate & brief duration can have a negative impact on tracing;
emitting a high volume signposts can lead to blocking, affecting performance,
and total volume makes human review of the trace harder because of the noise.

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

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

Change "target.save-jit-objects" to "target.save-jit-objects-dir".
The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure). Thi

Change "target.save-jit-objects" to "target.save-jit-objects-dir".
The old command wrote to CWD, which doesn't always work, and if it
didn't, there was no workaround (and it crashed on failure). This
patch changed the setting to provide a directory to save the objects
to.

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

show more ...

Fix the order of modules-loaded event and the resultant breakpoint-changed event.

The order used to be breakpoint-changed first, which didn't make much sense.

Differential Revision: https://reviews

Fix the order of modules-loaded event and the resultant breakpoint-changed event.

The order used to be breakpoint-changed first, which didn't make much sense.

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

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

[lldb] Make ReadCStringFromMemory default to read from the file-cache.

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

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