As seen in #177570, this code has a bunch of corner cases, does not
handle ANSI codes properly and does not handle unicode at all. That's
enough to fix that we need some tests to make it clear where we're
starting from.
The body of OutputFormattedUsageText is moved into a utility in the
AnsiTerminal.h header and tests added to the existing
AnsiTerminalTest.cpp.
Some results are known to be wrong. Some that cause crashes are
commented out, to be enabled once fixed.
Add a step to drain the init sequences emitted by the ConPTY before
attaching it to the debuggee.
A ConPTY (PseudoConsole) emits init sequences which flush the screen and
contain the name of the program (ESC[2J for clear screen, ESC[H for
cursor home and more). It's not desirable to filter them out: if a
debuggee also emits them, lldb would filter that output as well. To work
around this, the ConPTY is drained by attaching a dummy process to it,
consuming the init sequences and then attaching the actual debuggee.
---------
Co-authored-by: Nerixyz <nero.9@hotmail.de>
Several languages support some sort of "breakpoint" function, which adds
ISA-specific instructions to generate an interrupt at runtime. However,
on some platforms, these instructions don't increment the program
counter. When LLDB sets these instructions it isn't a problem, as we
remove them before continuing, then re-add them after stepping over the
location. However, for breakpoint sequences that are part of the
inferior process, this doesn't happen - and so users might be left
unable to continue past the breakpoint without manually interfering with
the program counter.
This patch adds logic to LLDB to intercept SIGTRAPs, inspect the bytes
of the inferior at the program counter, and if the instruction looks
like a BRK or BKPT or similar, increment the pc by the size of the
instruction we found. This unifies platform behaviour (e.g. on x86_64,
LLDB debug sessions already look like this) and improves UX (in my
opinion, but I think it beats messing with stuff every break).
Some ISAs (like AArch64) require slightly different handling, as while
there are multiple possible instructions, we should be careful only to
find the ones likely to have been emitted by a compiler backend, and not
those inserted from (for example) the UB sanitizer, or any others.
There is an existing builtin-debugtrap test which was under the macos
folder before. I've now moved that to "functionalities", made it pure C
only, and updated it a little bit so that it works regardless of
platform.
What I've not done is change the existing code in debugserver which was
added by Jason Molenda about five years ago
(https://reviews.llvm.org/D91238, 92b036d). It might not be required any
more after this change. Reading the history there, it seems like it was
agreed that this behaviour (skipping over unknown bps) was the desired
end goal.
Fixes#56268
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
In #168245, I attempted to dump the available settings to Markdown. That
required a full build of LLDB. However, to build the docs, only the swig
wrappers should need to be compiled. The comment was that we should be
able to use the definitions from the TableGen files.
Currently, the property definitions in don't have information about the
path where they will be available. They only contain a `Definition`
which groups properties, so they can be added to
`OptionValueProperties`.
With this PR, I'm adding the path for each property definition. For
example, `symbols.enable-external-lookup` would have `Name =
enable-external-lookup, Path = symbols`. In LLDB itself, we don't need
this path, we only need it for the documentation. To avoid mismatches
between the actual path and the declared one, I added a debug-only check
when a property group is added to a parent
(`OptionValueProperties::AppendProperty`).
The TableGen emitter for the properties now additionally emits
`g_{definition}_properties_def`, which includes both the array of
properties and the expected path. This constant has to be used to
initialize a `OptionValueProperties`.
I couldn't test this for everything (e.g. IntelPT or ProcessKDP), but
the necessary changes are simple: (1) set the `Path` in the TableGen
file, (2) update `initialize` to use `_def`.
Get the shared cache filepath and uuid that the inferior process is
using from debugserver, try to open that shared cache on the lldb host
mac and if the UUID matches, index all of the binaries in that shared
cache. When looking for binaries loaded in the process, get them from
the already-indexed shared cache.
Every time a binary is loaded, PlatformMacOSX may query the shared cache
filepath and uuid from the Process, and pass that to
HostInfo::GetSharedCacheImageInfo() if available (else fall back to the
old HostInfo::GetSharedCacheImageInfo method which only looks at lldb's
own shared cache), to get the file being requested.
ProcessGDBRemote caches the shared cache filepath and uuid from the
inferior, once it has a non-zero UUID. I added a lock for this ivar
specifically, so I don't have 20 threads all asking for the shared cache
information from debugserver and updating the cached answer. If we never
get back a non-zero UUID shared cache reply, we will re-query at every
library loaded notification. debugserver has been providing the shared
cache UUID since 2013, although I only added the shared cache filepath
field last November.
Note that a process will not report its shared cache filepath or uuid at
initial launch. As dyld gets a chance to execute a bit, it will start
returning binaries -- it will be available at the point when libraries
start loading. (it won't be available yet when the binary & dyld are the
only two binaries loaded in the process)
I tested this by disabling lldb's scan of its own shared cache
pre-execution -- only loading the system shared cache when the inferior
process reports that it is using that. I got 6-7 additional testsuite
failures running lldb like that, because no system binaries were loaded
before exeuction start, and the tests assumed they would be.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
This ivar was passed to the thread function for the private state thread
- mostly because the equivalent variable was passed in in the original
version of the code. But it was never used, so I didn't notice that the
ivar equivalent wasn't being initialized. I'm going to keep the ivar
because it will be useful when debugging to easily see whether you are
on the main or secondary private state thread.
So in this change, I set m_is_secondary_thread properly in the
constructor, but remove passing it to the thread function since it
wasn't needed there.
When working with a MainLoop, if the file reaches the EOF it will
immediately fire the read handle callback. We cannot readily determine
if the file is at EOF or if the file is pointing to a socket/pipe that
has consumed all the current data in the buffer but the remote end has
not yet hung up. This is causing JSONTransport to continuously fire the
OnRead callback trigging repeated calls to the
`MessageHandler::OnClose`.
Since MainLoop does not perform the actual read, we need to adjust the
behavior of JSONTransport to fully own the read handle.
This change moves the ownership of the `MainLoop::ReadHandleUP` and
additionally own a reference to the `MainLoop` itself to ensure the loop
outlives the JSONTransport object.
This allows us to remove the handle immediately when we detect an EOF /
hang up has occurred.
Taking advantage of a few new SPI in macOS 26.4 libdyld, it is possible
for lldb to load binaries out of a shared cache binary blob, instead of
needing discrete files on disk. lldb has had one special case where it
has done this for years -- if the debugee process and lldb itself are
using the same shared cache, it could create ObjectFiles based on its
own memory contents. This new method requires only the shared cache on
disk, not depending on it being mapped into lldb's address space
already.
In HostInfoMacOSX.mm, we create an array of binaries in lldb's shared
cache, by one of two methods depending on the availability of SPI/SDKs.
This PR adds a new third method for loading lldb's shared cache off disk
as a proof of concept. It will prefer this new method when the needed
SPI are available at runtime. There is also a user setting to disable
this new method in case we uncover a problem as it is deployed.
I did change the internal store of the shared cache files from a single
array, to being organized by shared cache UUIDs, so we can have multiple
shared caches indexed in the future.
In HostInfoBase.h's SharedCacheImageInfo class, you can now create an
ImageInfo with a DataExtractorSP or a void* baton. I added GetUUID and
GetExtractor methods, and the latter will use the libdyld SPI to map the
segments for a specific binary into lldb's memory and return a
DataExtractorSP.
The setting is currently called symbols.shared-cache-binary-loading.
In DynamicLoaderDarwin::FindTargetModuleForImageInfo there was an
ordering mistake where we would always consult the HostInfoMacOSX.mm
shared cache provider, instead of checking lldb's own global module
cache first when looking for a binary, resulting in creating a new
Module repeatedly for shared cache binaries with the new method, parsing
the symbol table repeatedly. I fixed the ordering so we look at existing
Modules before we check the shared cache for one.
In ObjectFileMachOTest, it tests a TEXT and a DATA symbol, checking that
the contents of the function/data object match the bytes we got from the
shared cache. The test was using a DATA_DIRTY symbol, which was fine
when using lldb's own shared cache memory, but when we worked on the
shared cache binary on-disk directly, we were seeing different values
for the bytes because of relocations in there. I changed this to a
constant DATA symbol.
rdar://148939795
---------
Co-authored-by: Jonas Devlieghere <jonas@devlieghere.com>
Co-authored-by: Alex Langford <nirvashtzero@gmail.com>
This changes VirtualDataExtractor's GetByteSize to return the virtual
byte size of the buffer (external users only understand the data
contents in terms of the virtual sizes & offsets). There are check
methods in DataExtractor that check they are not going off the end of a
buffer, they usually use the BytesLeft() method. There are a couple of
callers of BytesLeft() externally, but it is predominantly an internal
use API. I have BytesLeft() use the physical size of the buffer, not the
virtual size, for the benefit of the DataExtractor methods. (and to
avoid duplicating all of them down in VirtualDataExtractor)
Another problem is the we call SetData on DataExtractorSP's (e.g. see
the ObjectFile ctor) with the DataBuffer it already has, an offset of 0,
and the GetByteSize. A no-op for a DataExtractor that is already using
that DataBuffer. But SetData would try to use that length as a physical
size, and truncate the buffer that the DataExtractor would accept.
I added VirtualDataExtractor subclass methods for the SetData's, detect
(1) data being added to an uninitialized DataExtractor, (2) the same
data / offset / length as currently being used is added to the
DataExtractor (a no-op), or (3) we're genuinely changing the data source
or setting an offset / length that is different. This final case we're
not ready to handle today, I added asserts for them so we can catch it
in debug builds, and then I clear the LookupTable and add a no-op entry
so this extractor will behave like a plain DataExtractor -- because I
don't know better to do. If we genuinely need to handle this case, and
I'm pretty sure we don't need to, I'd have to assume that we're taking a
subset of the original data source (an offset & length), so we'd need to
update all of the LookupTable entries to reflect the new offsets, and
remove entries that are no longer referring to the subsetted range. I'll
leave that until there's any evidence it's actually needed.
rdar://148939795
We have a problem when some code on the private state thread needs to
run an expression. The private state thread is the one that fetches
"raw" events from the Process Plugin and decides how to handle them. But
if the private state thread needs to fetch the processed events to drive
running an expression, it can't also be the thread processing the raw
events.
We solve this by swapping in a modal private state thread just to handle
the events from the expression evaluation. That worked until you could
cause the expression evaluation to happen from Python, because then it
wasn't just the fetching of events that matter, but also the state of
the process and the state of the runlocks. The modal private state
thread is really a modal version of the thread and its associated state.
This patch gathers all the relevant control parameters into a structure
which we can swap in and out when needed.
It also adds a test using the new "was_hit" breakpoint resolver
affordance, which, since it acts as an asynchronous breakpoint callback,
gets run on the private state thread, showing that with the change we
can call expressions in the `was_hit` callback without problems.
We want to reload the call stack whenever the frame providers are
updated. To do so, we now emit a `eBroadcastBitStackChanged` on all
threads whenever any changes to the frame providers take place.
I found this very useful while iterating on a frame provider in
lldb-dap. So far, the new frame provider only took effect after
continuing execution. Now the backtrace in VS-Code gets refreshed
immediately upon running `target frame-provider add`.
I noticed that Module::GetMemoryObjectFile populates a Status object
upon error but it's effectively dropped on the floor. Instead, the
clients can report the error as desired.
At the moment, all clients are either (1) consuming the error because
it's only trying to find a module, or (2) log the error and bail out
early. I tried to preserve existing behavior as faithfully as possible.
Depends on:
* https://github.com/llvm/llvm-project/pull/177921
* https://github.com/llvm/llvm-project/pull/177926
(only last commit is relevant for this review)
This patch emits a workaround suggestion (in the form of a `note:`
diagnostic) when an expression fails due to trying to mutate state/call
functions with CV-qualifiers that are disallowed by C++ language rules
based on the context the expression is evaluated in. The note looks as
follows:
```
(lldb) expr next.method()
˄
╰─ error: 'this' argument to member function 'method' has type 'const Bar', but function is not marked const
note: Ran expression as 'C++14'.
note: note: 'method' declared here
note: Possibly trying to mutate object in a const context. Try running the expression with: expression --c++-ignore-context-qualifiers -- <your expression>
```
The motivation here is that we don't want to pollute the SBAPI with
getters/setters for expression evaluation options that only apply to a
single language. The ultimate goal would be to have plugins register
additional options to the `expression` command when the plugin is
loaded. This patch only provides the minimal `SBExpressionOptions`
interface to set an option with an arbitrary name, which the language
plugin knows how to interpret. The underlying options dictionary is an
`StructuredData::Dictionary` so we can map strings to values of any
type. But the SBAPI just exposes setting a boolean value. Future
overloads of `SetLanguageOption` can provide setters for more types.
The boolean setter/getter will be used for the C++-specific option being
introduced in: https://github.com/llvm/llvm-project/pull/177926
Depends on:
* https://github.com/llvm/llvm-project/pull/178904
(only last commit is relevant for the review)
This is part of a patch series to clean up the
TypeSystemClang::IsFloatingPointType API. The `is_complex` parameter is
rarely checked. This patch introduces a `CompilerType::IsComplexType`
API which callers that previously checked `is_complex` can use instead.
This will also allow us to remove `CompilerType::IsFloat`, which is just
`IsFloatingPointType` that ignores the `is_complex` parameter.
This is part of a patch series to clean up the
`TypeSystemClang::IsFloatingPointType` API. Currently the API is a bit
of a foot-gun because it returns `true` for both Complex floats and
vector types whose element types are floats, but most call-sites
probably don't handle these correctly. The former aligns with the
`clang::Type::isFloatingType` API, but the latter doesn't. This specific
implementation choice will be addressed in a separate patch. This patch
adds a new `CompilerType::IsRealFloatingPointType` API which clients can
use to query about non-complex floats (named after the similarly named
`clang::Type::isRealFloatingType`).
This allows us to clean up some of the callers which only wanted to
handle non-complex floats. I cleaned those up as part of this patch.
Wherever we checked for `is_float && !is_complex && !is_vector_type` i
just replaced it with the new API.
On encountering complex/vector floats, some of the ABI plugins would set
an error but then immediately overwrite the error to something else. I
just removed those branches entirely, since it was essentially dead
code.
Some of the diff is large because of un-indentation when we remove
if-guards, so I would recommend turning off white-space diff when
reviewing.
When a user holds an SBFrame reference and then triggers an inferior
function
call (via expression evaluation or GetExtendedBacktraceThread),
variables in
that frame become inaccessible with "register fp is not available"
errors.
This happens because inferior function calls execute through
ThreadPlanCallFunction, which calls ClearStackFrames() during cleanup to
invalidate the unwinder state. ExecutionContextRef objects in the old
SBFrames
were tracking StackFrameLists via weak_ptr, which became stale when
ClearStackFrames() created new instances.
The fix uses stable StackFrameList identifiers that persist across
ClearStackFrames():
- ID = 0: Normal unwinder frames (constant across all instances)
- ID = sequential counter: Scripted frame provider instances
ExecutionContextRef now stores the frame list ID instead of a weak_ptr,
allowing
it to resolve to the current StackFrameList with fresh unwinder state
after an
inferior function call completes.
The Thread object preserves the provider chain configuration
(m_provider_chain_ids and m_next_provider_id) across ClearStackFrames()
so
that recreated StackFrameLists get the same IDs. When providers need to
be
recreated, GetStackFrameList() rebuilds them from the persisted
configuration.
This commit also fixes a deadlock when Python scripted frame providers
call
back into LLDB during frame fetching. The m_list_mutex is now released
before
calling GetFrameAtIndex() on the Python scripted frame provider to
prevent
same-thread deadlock. A dedicated m_unwinder_frames_sp member ensures
GetFrameListByIdentifier(0) always returns the current unwinder frames,
and
proper cleanup in DestroyThread() and ClearStackFrames() to prevent
modules
from lingering after a Thread (and its StackFrameLists) gets destroyed.
Added test validates that variables remain accessible after
GetExtendedBacktraceThread triggers an inferior function call to fetch
libdispatch Queue Info.
rdar://167027676
Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>
This patch adds plumbing to support the implementations of StackFrame::Get{*}Variable{*} on ScriptedFrame. The major pieces required are:
- A modification to ScriptedFrameInterface, so that we can actually call the python methods.
- A corresponding update to the python implementation to call the python methods.
- An implementation in ScriptedFrame that can get the variable list on construction inside ScriptedFrame::Create, and pass that list into the ScriptedFrame so it can get those values on request.
There is a major caveat, which is that if the values from the python side don't have variables attached, right now, they won't be passed into the scripted frame to be stored in the variable list. Future discussions around adding support for 'extended variables' when printing frame variables may create a reason to change the VariableListSP into a ValueObjectListSP, and generate the VariableListSP on the fly, but that should be addressed at a later time.
This patch also adds tests to the frame provider test suite to prove these changes all plumb together correctly.
Related radar: rdar://165708771
In a PR last month I changed the ObjectFile CreateInstance etc methods
to accept an optional DataExtractorSP instead of a DataBufferSP, and
retain the extractor in a shared pointer internally in all of the
ObjectFile subclasses. This is laying the groundwork for using a
VirtualDataExtractor for some Mach-O binaries on macOS, where the
segments of the binary are out-of-order in actual memory, and we add a
lookup table to make it appear that the TEXT segment is at offset 0 in
the Extractor, etc. Working on the actual implementation, I realized we
were still using DataBufferSP's in ModuleSpec and Module, as well as in
ObjectFile::GetModuleSpecifications.
I originally was making a much larger NFC change where I had all
ObjectFile subclasses operating on DataExtractors throughout their
implementation, as well as in the DWARF parser. It was a very large
patchset. Many subclasses start with their DataExtractor, then create
smaller DataExtractors for parts of the binary image - the string table,
the symbol table, etc., for processing.
After consideration and discussion with Jonas, we agreed that a
segment/section of a binary will never require a lookup table to access
the bytes within it, so I changed
VirtualDataExtractor::GetSubsetExtractorSP to (1) require that the
Subset be contained within a single lookup table entry, and (2) return a
simple DataExtractor bounded on that byte range. By doing this, I was
able to remove all of my very-invasive changes to the ObjectFile
subclass internals; it's only when they are operating on the entire
binary image that care is needed.
One pattern that subclasses like ObjectFileBreakpad use is to take an
ArrayRef of the DataBuffer for a binary, then create a StringRef of
that, then look for strings in it. With a VirtualDataExtractor and
out-of-order binary segments, with gaps between them, this allows us to
search the entire buffer looking for a string, and segfault when it gets
to an unmapped region of the buffer. I added a
VirtualDataExtractor::GetSubsetExtractorSP(0) which gets the largest
contiguous memory region starting at offset 0 for this use case, and I
added a comment about what was being done there because I know it is not
obvious, and people not working on macOS wouldn't be familiar with the
requirement. (when we have a ModuleSpec with a DataExtractor, any of the
ObjectFile subclasses get a shot at Creating, so they all have to be
able to iterate on these)
rdar://148939795
## Description
Contribution to this topic [Rich Disassembler for
LLDB](https://discourse.llvm.org/t/rich-disassembler-for-lldb/76952),
this part.
```
The rich disassembler output should be exposed as structured data and made available through LLDB’s scripting API so more tooling could be built on top of this
```
----
This pr replaces #174847
As was suggested in [this
comment](https://github.com/llvm/llvm-project/pull/174847#issuecomment-3757015552),
implement access to variable annotations from `SBInstruction` class
itself.
Notes:
- ✅ did run black formatter on the python file;
## Testing
Run test with
```sh
./build/bin/lldb-dotest -v -p TestVariableAnnotationsDisassembler.py lldb/test/API/functionalities/disassembler-variables
```
all tests (9 existing + 1 newly added) are passing
<details>
<summary>screenshot 2026-01-23</summary>
build from the latest commit 08f00730b5768a8e3f7039d810084fabaaa24470
<img width="1506" height="562" alt="image"
src="https://github.com/user-attachments/assets/69516353-3432-47df-ae45-c40b51ec14c4"
/>
</details>
<details>
<summary>screenshot 2026-01-29</summary>
build from the latest commit f48a1a2c10f96a457ca6844be2ccc9406d3d57a0
<img width="1232" height="740" alt="image"
src="https://github.com/user-attachments/assets/9d104ce6-36c3-430b-98fe-f028f83a6b6d"
/>
</details>
---------
Signed-off-by: Nikita B <n2h9z4@gmail.com>
This patch adds support for:
- PyObject -> SBValueList (which was surprisingly not there before!)
- PyObject -> SBValue
- SBValue -> ValueObjectSP using the ScriptInterpreter
These three are the main remaining plumbing changes necessary before we can get to the meat of actually using ScriptedFrame to provide values to the printer/etc. Future patches build off this change in order to allow ScriptedFrames to provide variables and get values for variable expressions.
This patch moves ValueImpl and ValueLocker to ValueObject.{h,cpp}. This follows the example set in TypeImpl/SBType, where we have something that SBType uses internally that needs to be exposed in the layer below. In this case, SBValue uses ValueImpl, which wraps ValueObject. The wrapper helps avoid bugs, so we want to keep it, but the script interpreter needs to use it and said interpreter is conceptually *below* the SB layer...which means we can't use methods on SBValue.
This patch is purely the code motion part of that, future patches will actually make use of this moved code.
The current linux implementation has a 1 second timeout when polling for
memory pressure. lldb-dap may take up to an extra 1 second to shutdown.
Use an event file descriptor to immediately stop the memory monitor
thread.
Fixes#150220
During target creation for launch mode, the locate module callback was
not invoked for the main executable because the Target doesn't exist yet
when ModuleList::GetSharedModule is called. This prevented custom module
location logic from being applied to the main executable.
This change adds a PlatformSP to ModuleSpec so that GetSharedModule can
call the locate module callback using the Platform directly, even when
Target is not available. The Platform is now set on the ModuleSpec in
TargetList::CreateTargetInternal before calling ResolveExecutable.
Co-authored-by: George Hu <georgehuyubo@gmail.com>
# Summary
This patch ensures lldb will not try to read from a PseudoConsole if it
has not been opened.
# Original issue
https://github.com/llvm/llvm-project/pull/168729 introduces support for
the Windows ConPTY in `lldb-dap`. This caused a regression in `lldb`
which was not caught by our tests:
https://github.com/llvm/llvm-project/issues/175652.
This patch fixes https://github.com/llvm/llvm-project/issues/175652.
`lldb_private::ProcessLauncherWindows::LaunchProcess` connects the
debuggee to a PseudoConsole only if:
```cpp
if (hPC != INVALID_HANDLE_VALUE && launch_info.GetNumFileActions() == 0 && launch_info.GetFlags().Test(lldb::eLaunchFlagLaunchInTTY))
```
lldb needs to check the same condition in
`lldb_private::PlatformWindows::DebugProcess` to ensure that it does not
read from a PseudoConsole which has not been opened.
# Side effect
This patch reverts what https://github.com/llvm/llvm-project/pull/168729
did by adding ConPTY support.
https://github.com/llvm/llvm-project/pull/175812 is the proper fix,
however it's causing tests failures which we can't reliably reproduce at
desk. Given https://github.com/llvm/llvm-project/pull/168729 breaks
`22.x` lldb, it's better to revert the change ahead of the release of
`22.x` rather than pushing for the proper fix.
This commit improves the way how the example code attached to
`SBDebugger::GetSetting` method is rendered by Doxygen.
Co-authored-by: Matej Košík <matej.kosik@codasip.com>
This fixes the following warning, repeated multiple times:
llvm-project/lldb/include/lldb/Host/windows/PseudoConsole.h:69:2: warning: extra ';' outside of a function is incompatible with C++98 [-Wc++98-compat-extra-semi]
69 | }; // namespace lldb_private
| ^
We have many places where an ObjectFile subclass will take the
DataExtractor representing the entire binary, create a subsection of
that in a new DataExtractor for processing. For instance, an object file
might have symbol table entries with offsets into the string table. A
common code pattern is to create a DataExtractor representing the string
table, and then pulling out the c-strings based on those offsets from
the string table DataExtractor.
When code does this, it creates a new DataExtractor, copies the
Endianness and Wordsize from the original, copies the DataBufferSP from
the original, and specifies a new start and offset into the DataBuffer.
However, if the binary is actaully stored in a VirtualDataExtractor,
this code pattern loses the correct virtual-to-physical table
translation and will not work correctly. This new method simplifies this
common pattern, and correctly takes a subset of a VirtualDataExtractor.
The current implementation only allows a subset of a
VirtualDataExtractor that is contained within a single virtual entry
(LookupTable entry) and returns a DataExtractor with the corret offsets
calculated from the LookupTable. If we need to a VirtualDataExtractor to
create a Subset DataExtractor representing multiple separate virtual
ranges of data, we'll need to copy over the LookupTable entries that
cover all the bytes, and update them to be relative to the new
VirtualDataExtractor. It's a bit of work, and it's not needed right now,
so I'm not tackling that.
I am working on a larger PR which needs this new method. This PR
contains a unit test that uses it.
rdar://148939795
When you specify a filename to `process save core`, we'll write it in
the current working directory. In Xcode the CWD is `/` and you can't
generally write there.
```
(lldb) process save-core --style full foo
error: failed to save core file for process: Read-only file system
```
This PR improves the error message by including the output file when we
can't save core. However, just printing the filename isn't that much
more helpful, because FileSystem::Resolve only makes a path absolute if
it exists.
```
error: failed to save core file for process to 'foo': Read-only file system
```
Therefore I also modified the interface to add a flag to force resolve a
potentially non-exist path.
```
error: failed to save core file for process to '/foo': Read-only file system
```
Writing testcases for error handling that depends on specific DWARF is
very difficult and the resulting tests tend not to be very portable.
This patch adds a new setting to inject an error into variable
materialization, thus making it possible to write very simple source
code based tests for error handling instead.
This is primarily motivated by the Swift language plugin, but
functionality is generic and should be useful for other languages as
well.
