[lldb] Change setting descriptions to use StringRef instead of ConstString

These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstSt

[lldb] Change setting descriptions to use StringRef instead of ConstString

These probably do not need to be in the ConstString StringPool as they
don't really need any of the advantages that ConstStrings offer.
Lifetime for these things is always static and we never need to perform
comparisons for setting descriptions.

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

show more ...

[lldb] Change parameter type of StructuredData::ParseJSON

Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `P

[lldb] Change parameter type of StructuredData::ParseJSON

Instead of taking a `const std::string &` we can take an
`llvm::StringRef`. The motivation for this change is that many of the
callers of `ParseJSON` end up creating a temporary `std::string` from an existing
`StringRef` or `const char *` in order to satisfy the API. There's no
reason we need to do this.

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

show more ...

[lldb] Use StringMap::contains (NFC)

[lldb] Read register fields from target XML

This teaches ProcessGDBRemote to look for "flags" nodes
in the target XML that tell you what fields a register has.

https://sourceware.org/gdb/onlinedocs

[lldb] Read register fields from target XML

This teaches ProcessGDBRemote to look for "flags" nodes
in the target XML that tell you what fields a register has.

https://sourceware.org/gdb/onlinedocs/gdb/Target-Description-Format.html

It will check for various invalid inputs like:
* Flags nodes with 0 fields in them.
* Start or end being > the register size.
* Fields that overlap.
* Required properties not being present (e.g. no name).
* Flag sets being redefined.

If anything untoward is found, we'll just drop the field or the
flag set altogether. Register fields are a "nice to have" so LLDB
shouldn't be crashing because of them, instead just log anything
we throw away. So the user can fix their XML/file a bug with their
vendor.

Once that is done it will sort the fields and pass them to
the RegisterFields class I added previously.

There is no way to see these fields yet, so tests for this code
will come later when the formatting code is added.

The fields are stored in a map of unique pointers on the
ProcessGDBRemote class. It will give out raw pointers on the
assumption that the GDB process lives longer than the users
of those pointers do. Which means RegisterInfo is still a trivial struct
but we are properly destroying the fields when the GDB process ends.

We can't store the fields directly in the map because adding new
items may cause its storage to be reallocated, which would invalidate
pointers we've already given out.

Reviewed By: jasonmolenda, JDevlieghere

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

show more ...

Remove AArch64 out of MIPS watchpoint-skip, doc wp description

Watchpoints from lldb-server are sent in the stop info packet
as a `reason:watchpoint` and `description:asciihex` keys; the
latter's as

Remove AArch64 out of MIPS watchpoint-skip, doc wp description

Watchpoints from lldb-server are sent in the stop info packet
as a `reason:watchpoint` and `description:asciihex` keys; the
latter's asciihex has one to three integer values. This patch
documents the purpose of those three different numbers, and
clarifies the behavior on MIPS with the third number which is
outside the range of any watched memory range means to silently
skip the watchpoint.

lldb was previously using this silently skip watchpoint behavior
for AArch64 as well, but in the case of AArch64 we see a watchpoint
address outside of a watched memory range when the write BEGINS
before the watched memory range, but extends in to it. We don't
want to silently skip these.

Differential Revision: https://reviews.llvm.org/D147816
rdar://83996471

show more ...

Revert "[lldb] Move UnixSignals creation into Platform plugins"

This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way

Revert "[lldb] Move UnixSignals creation into Platform plugins"

This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.

show more ...

[lldb] Move UnixSignals creation into Platform plugins

The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is

[lldb] Move UnixSignals creation into Platform plugins

The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.

This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.

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

show more ...

[LLDB] add arch-specific watchpoint behavior defaults to lldb

lldb was originally designed to get the watchpoint exception behavior
from the gdb remote serial protocol stub -- exceptions are either

[LLDB] add arch-specific watchpoint behavior defaults to lldb

lldb was originally designed to get the watchpoint exception behavior
from the gdb remote serial protocol stub -- exceptions are either
received before the instruction executes, or after the instruction
has executed. This behavior was reported via two lldb extensions
to gdb RSP, so generic remote stubs like gdbserver or a JTAG stub,
would not tell lldb which behavior was correct, and it would default
to "exceptions are received after the instruction has executed".
Two architectures hard coded their correct "exceptions before
instruction" behavior, to work around this issue.

Most architectures have a fixed behavior of watchpoint exceptions,
and we can center that information in lldb. We can allow a remote
stub to override the default behavior via our packet extensions
if it's needed on a specific target.

This patch also separates the fetching of the number of watchpoints
from whether exceptions are before/after the insn. Currently if
lldb couldn't fetch the number of watchpoints (not really needed), it
also wouldn't get when exceptions are received, and watchpoint
handling would fail. lldb doesn't actually use the number of
watchpoints for anything beyond printing it to the user.

Differential Revision: https://reviews.llvm.org/D143215
rdar://101426626

show more ...

Do qProcessInfo-hint binary loading later in Process setup

The remote stub may give lldb hints about binaries to
be loaded, especially in a firmware type environment, and
relay those hints in the qP

Do qProcessInfo-hint binary loading later in Process setup

The remote stub may give lldb hints about binaries to
be loaded, especially in a firmware type environment, and
relay those hints in the qProcessInfo response. The
binary loading was done very early in Process setup, before
we had any threads, and this made it complicated for people
to write dSYM python scripts which need access to a thread.
Delay the binary loading until a bit later in the Process
startup.

Differential Revision: https://reviews.llvm.org/D141972
rdar://104235301

show more ...

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/

[lldb] Use std::optional instead of llvm::Optional (NFC)

This patch replaces (llvm::|)Optional< with std::optional<. I'll post
a separate patch to clean up the "using" declarations, #include
"llvm/ADT/Optional.h", etc.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optiona

[lldb] Add #include <optional> (NFC)

This patch adds #include <optional> to those files containing
llvm::Optional<...> or Optional<...>.

I'll post a separate patch to actually replace llvm::Optional with
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

Launch state discoverable in Darwin, use for SafeToCallFunctions

The dynamic linker on Darwin, dyld, can provide status of
the process state for a few significant points early on,
most importantly,

Launch state discoverable in Darwin, use for SafeToCallFunctions

The dynamic linker on Darwin, dyld, can provide status of
the process state for a few significant points early on,
most importantly, when libSystem has been initialized and it
is safe to call functions behind the scenes. Pipe this
information up from debugserver to DynamicLoaderMacOS, for
the DynamicLoader::IsFullyInitialized() method, then have
Thread::SafeToCallFunctions use this information. Finally,
for the two utility functions in the AppleObjCRuntimeV2
LanguageRuntime plugin that I was fixing, call this method
before running our utility functions to collect the list of
objc classes registered in the runtime.

User expressions will still be allowed to run any time -
we assume the user knows what they are doing - but these
two additional utility functions that they are unaware of
will be limited by this state.

Differential Revision: https://reviews.llvm.org/D139054
rdar://102436092
can probably make function calls.

show more ...

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of ma

[lldb] Use std::nullopt instead of None (NFC)

This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

show more ...

[lldb][nfc] Deindent ProcessGDBRemote::SetThreadStopInfo by two levels

[lldb] Place PlatformQemu Properties into anonymous namespace

It's fine right now, but will break as soon as someone else declares a
PluginProperties class in the same way.

Also tighten up the scop

[lldb] Place PlatformQemu Properties into anonymous namespace

It's fine right now, but will break as soon as someone else declares a
PluginProperties class in the same way.

Also tighten up the scope of the anonymous namespaces surrounding the
other PluginProperties classes.

show more ...

[lldb/gdb-server] Better reporting of launch errors

Use our "rich error" facility to propagate error reported by the stub to
the user. lldb-server reports rich launch errors as of D133352.

To make

[lldb/gdb-server] Better reporting of launch errors

Use our "rich error" facility to propagate error reported by the stub to
the user. lldb-server reports rich launch errors as of D133352.

To make this easier to implement, and reduce code duplication, I have
moved the vRun/A/qLaunchSuccess handling into a single
GDBRemoteCommunicationClient function.

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

show more ...

[lldb] Log when we cannot find an equivalent for a gdb register type

This happens if the type is described elsewhere in target xml as a
<flags> or <struct>.

Also hardcode the function names into th

[lldb] Log when we cannot find an equivalent for a gdb register type

This happens if the type is described elsewhere in target xml as a
<flags> or <struct>.

Also hardcode the function names into the log messages because
if you use __FUNCTION__ in a lambda you just get "operator()".

Reviewed By: clayborg

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

show more ...

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outli

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

show more ...

[lldb] Reset breakpoint hit count before new runs

A common debugging pattern is to set a breakpoint that only stops after
a number of hits is recorded. The current implementation never resets
the hi

[lldb] Reset breakpoint hit count before new runs

A common debugging pattern is to set a breakpoint that only stops after
a number of hits is recorded. The current implementation never resets
the hit count of breakpoints; as such, if a user re-`run`s their
program, the debugger will never stop on such a breakpoint again.

This behavior is arguably undesirable, as it renders such breakpoints
ineffective on all but the first run. This commit changes the
implementation of the `Will{Launch, Attach}` methods so that they reset
the _target's_ breakpoint hitcounts.

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

show more ...

Add mach-o corefile support for platform binaries

Add support for recognizing a platform binary in the ObjectFileMachO
method that parses the "load binary" LC_NOTEs in a corefile.

A bit of reorgani

Add mach-o corefile support for platform binaries

Add support for recognizing a platform binary in the ObjectFileMachO
method that parses the "load binary" LC_NOTEs in a corefile.

A bit of reorganization to ProcessMachCore::DoLoadCore to separate
all of the unrelated things being done in that method into their own
separate methods, as well as small fixes to improve the handling of
a corefile with multiple kernel images in the corefile.

Differential Revision: https://reviews.llvm.org/D133680
rdar://98754861

show more ...

[lldb] Fixed a number of typos

I went over the output of the following mess of a command:

(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel
--xargs -0 cat | aspell list --mode=n

[lldb] Fixed a number of typos

I went over the output of the following mess of a command:

(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel
--xargs -0 cat | aspell list --mode=none --ignore-case | grep -E
'^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' |
aspell pipe -W3 | grep : | cut -d' ' -f2 | less)

and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).

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

show more ...

Recognize a platform binary in ProcessGDBRemote which determines plugins

Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the bina

Recognize a platform binary in ProcessGDBRemote which determines plugins

Complete support of the binary-addresses key in the qProcessInfo packet
in ProcessGDBRemote, for detecting if one of the binaries needs to be
handled by a Platform plugin, and can be used to set the Process'
DynamicLoader plugin and the Target's Platform plugin.

Implement this method in PlatformDarwinKernel to recognize a kernel
fileset at that address, find the actual kernel address in the
fileset, set DynamicLoaderDarwinKernel and PlatformDarwinKernel
in the Process/Target; register the kernel address with the dynamic
loader so it will be loaded later during attach.

This patch only addresses the live debug scenario with a gdb remote
serial protocol connection. I'll handle corefiles in a subsequent
patch that builds on this.

Differential Revision: https://reviews.llvm.org/D133534
rdar://98754861

show more ...

[gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

Move the broadcasting support from GDBRemoteCommunication
to GDBRemoteClientBase since this is where it is actually used. Remove
GDB

[gdb-remote] Move broadcasting logic down to GDBRemoteClientBase

Move the broadcasting support from GDBRemoteCommunication
to GDBRemoteClientBase since this is where it is actually used. Remove
GDBRemoteCommunication and subclass constructor arguments left over
after Communication cleanup.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133427

show more ...

[lldb] [Core] Split read thread support into ThreadedCommunication

Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used

[lldb] [Core] Split read thread support into ThreadedCommunication

Split the read thread support from Communication into a dedicated
ThreadedCommunication subclass. The read thread support is used only
by a subset of Communication consumers, and it adds a lot of complexity
to the base class. Furthermore, having a dedicated subclass makes it
clear whether a particular consumer needs to account for the possibility
of read thread being running or not.

The modules currently calling `StartReadThread()` are updated to use
`ThreadedCommunication`. The remaining modules use the simplified
`Communication` class.

`SBCommunication` is changed to use `ThreadedCommunication` in order
to avoid changing the public API.

`CommunicationKDP` is updated in order to (hopefully) compile with
the new code. However, I do not have a Darwin box to test it, so I've
limited the changes to the bare minimum.

`GDBRemoteCommunication` is updated to become a `Broadcaster` directly.
Since it does not inherit from `ThreadedCommunication`, its event
support no longer collides with the one used for read thread and can
be implemented cleanly. The support for
`eBroadcastBitReadThreadDidExit` is removed from the code -- since
the read thread was not used, this event was never reported.

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D133251

show more ...

[lldb] [gdb-remote] Use Communication::WriteAll() over Write()

Replace the uses of Communication::Write() with WriteAll() to avoid
partial writes. None of the call sites actually accounted for that

[lldb] [gdb-remote] Use Communication::WriteAll() over Write()

Replace the uses of Communication::Write() with WriteAll() to avoid
partial writes. None of the call sites actually accounted for that
possibility and even if it is unlikely to actually happen, there doesn't
seem to be any real harm from using WriteAll() instead.

Ideally, we'd remove Write() from the public API. However, that would
change the API of SBCommunication. The alternative would be to alias it
to WriteAll().

Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D132395

show more ...