Only set the "low" address masks when only one adressable bits specified

qHostInfo / stop-reply packet / LC_NOTE "addrable bits" can all
specify either a single value for all address masks, or separ

Only set the "low" address masks when only one adressable bits specified

qHostInfo / stop-reply packet / LC_NOTE "addrable bits" can all
specify either a single value for all address masks, or separate
masks for low and high memory addresses.

When the same number of addressing bits are used for all addresses,
we use the "low memory" address masks for everything. (or another
way, if the high address masks are not set, we use the low address
masks with the assumption that all memory is using the same mask --
the most common situation).

I was setting low and high address masks when I had a single value
from these metadata, but that gave the impression that the high
address mask was specified explicitly. After living on the code
a bit, it's clearly better to only set the high address masks when
we have a distinct high address mask value.

This patch is the minor adjustment to behave that way.

show more ...

hi/low addr space bits can be sent in stop-rely packet

Add support for the `low_mem_addressing_bits` and
`high_mem_addressing_bits` keys in the stop reply packet,
in addition to the existing `addres

hi/low addr space bits can be sent in stop-rely packet

Add support for the `low_mem_addressing_bits` and
`high_mem_addressing_bits` keys in the stop reply packet,
in addition to the existing `addressing_bits`. Same
behavior as in the qHostInfo packet.

Clean up AddressableBits so we don't need to check if
any values have been set in the object before using it
to potentially update the Process address masks.

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

show more ...

Update qHostInfo/LC_NOTE so multiple address bits can be specified

On AArch64 systems, we may have different page table setups for
low memory and high memory, and therefore a different number of
bit

Update qHostInfo/LC_NOTE so multiple address bits can be specified

On AArch64 systems, we may have different page table setups for
low memory and high memory, and therefore a different number of
bits used for addressing depending on which half of memory the
address is in.

This patch extends the qHostInfo and LC_NOTE "addrable bits" so
that it can specify the number of addressing bits in high memory
and in low memory separately. It builds on the patch I added in
https://reviews.llvm.org/D151292 where Process tracks the separate
address masks, and there is a user setting to set them manually.

Differential Revision: https://reviews.llvm.org/D157667
rdar://113225907

show more ...

[gdb-remote] Sort entries in QEnvironment*

Similar to ae316ac66ffff430997e342772fc4629c1acece0 for
QEMU_(UN)SET_ENV.
The iteration order of StringMap is not guaranteed to be deterministic.
Sort the

[gdb-remote] Sort entries in QEnvironment*

Similar to ae316ac66ffff430997e342772fc4629c1acece0 for
QEMU_(UN)SET_ENV.
The iteration order of StringMap is not guaranteed to be deterministic.
Sort the entries to give deterministic packets for the tests added by
D108018.

show more ...

[lldb] Check that qLaunchGDBServer packet does not return an error

While looking at https://github.com/llvm/llvm-project/issues/61955
I noticed that when we send qLaunchGDBServer we check that we go

[lldb] Check that qLaunchGDBServer packet does not return an error

While looking at https://github.com/llvm/llvm-project/issues/61955
I noticed that when we send qLaunchGDBServer we check that we got a response
but not what kind of response it was.

I think this was why the bug reporter saw:
(lldb) run
error: invalid host:port specification: '[192.168.64.2]'

The missing port is because we went down a path we only should have
chosen if the operation succeeded. Since we didn't check, we went ahead
with an empty port number.

To test this I've done the following:
* Make a temporary copy of lldb-server.
* Run that as a platform.
* Remove the copy.
* Attempt to create and run a target.

This fails because the running lldb-server will try to invoke itself
and it no longer exists.

Reviewed By: jasonmolenda

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

show more ...

[lldb][NFCI] Remove ConstString from GDBRemoteCommunicationClient::ConfigureRemoteStructuredData

ConstString's benefits are not being utilized here, StringRef is
sufficient.

Differential Revision:

[lldb][NFCI] Remove ConstString from GDBRemoteCommunicationClient::ConfigureRemoteStructuredData

ConstString's benefits are not being utilized here, StringRef is
sufficient.

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

show more ...

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for bo

[lldb] Add support for negative integer to {SB,}StructuredData

This patch refactors the `StructuredData::Integer` class to make it
templated, makes it private and adds 2 public specialization for both
`int64_t` & `uint64_t` with a public type aliases, respectively
`SignedInteger` & `UnsignedInteger`.

It adds new getter for signed and unsigned interger values to the
`StructuredData::Object` base class and changes the implementation of
`StructuredData::Array::GetItemAtIndexAsInteger` and
`StructuredData::Dictionary::GetValueForKeyAsInteger` to support signed
and unsigned integers.

This patch also adds 2 new `Get{Signed,Unsigned}IntegerValue` to the
`SBStructuredData` class and marks `GetIntegerValue` as deprecated.

Finally, this patch audits all the caller of `StructuredData::Integer`
or `StructuredData::GetIntegerValue` to use the proper type as well the
various tests that uses `SBStructuredData.GetIntegerValue`.

rdar://105575764

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

Signed-off-by: Med Ismail Bennani <ismail@bennani.ma>

show more ...

Re-land "[lldb] Expose a const iterator for SymbolContextList"

Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications
to fix tests.
I originally reverted this because it caused a test

Re-land "[lldb] Expose a const iterator for SymbolContextList"

Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications
to fix tests.
I originally reverted this because it caused a test to fail on Linux.
The problem was that I inverted a condition on accident.

show more ...

Revert "[lldb] Expose a const iterator for SymbolContextList"

This reverts commit 04aa943be8ed5c03092e2a90112ac638360ec253.

This broke the debian buildbot and I'm not sure why. Reverting so I can
i

Revert "[lldb] Expose a const iterator for SymbolContextList"

This reverts commit 04aa943be8ed5c03092e2a90112ac638360ec253.

This broke the debian buildbot and I'm not sure why. Reverting so I can
investigate.

show more ...

[lldb] Expose a const iterator for SymbolContextList

There are many situations where we'll iterate over a SymbolContextList
with the pattern:
```
SymbolContextList sc_list;
// Fill in sc_list here
f

[lldb] Expose a const iterator for SymbolContextList

There are many situations where we'll iterate over a SymbolContextList
with the pattern:
```
SymbolContextList sc_list;
// Fill in sc_list here
for (auto i = 0; i < sc_list.GetSize(); i++) {
SymbolContext sc;
sc_list.GetSymbolAtContext(i, sc);

// Do work with sc
}
```
Adding an iterator to iterate over the instances directly means we don't
have to do bounds checking or create a copy of every element of the
SymbolContextList.

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

show more ...

[lldb] Remove distribution_id from ArchSpec

The qHostInfo packet in the gdb-remote communication protocol specifies
that distribution_id can be set, so lldb handles that. But we store that
in the Ar

[lldb] Remove distribution_id from ArchSpec

The qHostInfo packet in the gdb-remote communication protocol specifies
that distribution_id can be set, so lldb handles that. But we store that
in the ArchSpec representing the "Host" platform (whatever platform the
debug server is running on). This field is otherwise unused in ArchSpec,
so it would be a lot easier if we stored that information at the
gdb-remote communication layer.

Sidenote: The distribution_id field is currently unused but I did not
want to remove it in case some folks found it useful (e.g. in downstream
forks).

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

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

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

Revert "[lldb] Remove redundant .c_str() and .get() calls"

This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd.

This has broken all LLDB buildbots:
https://lab.llvm.org/buildbot/#/builders

Revert "[lldb] Remove redundant .c_str() and .get() calls"

This reverts commit fbaf48be0ff6fb24b9aa8fe9c2284fe88a8798dd.

This has broken all LLDB buildbots:
https://lab.llvm.org/buildbot/#/builders/68/builds/44990
https://lab.llvm.org/buildbot/#/builders/96/builds/33160

show more ...

[lldb] Remove redundant .c_str() and .get() calls

Removing .c_str() has a semantics difference, but the use scenarios
likely do not matter as we don't have NUL in the strings.

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] Prevent an infinite loop while reading memory regions

A malformed qMemoryRegionInfo response can easily trigger an infinite
loop if regions end (base + size) wraps the address space. A
parti

[lldb] Prevent an infinite loop while reading memory regions

A malformed qMemoryRegionInfo response can easily trigger an infinite
loop if regions end (base + size) wraps the address space. A
particularly interesting is the case where base+size=0, which a stub
could use to say that the rest of the memory space is unmapped, even
though lldb expects 0xff... in this case.

One could argue which behavior is more correct (technically, the
current behavior does not say anything about the last byte), but unless
we stop using 0xff... to mean "invalid address", that discussion is very
academic. This patch truncates address ranges which wraps the address
space, which handles the zero case as well as other kinds of malformed
packets.

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

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] [gdb-remote] Include PID in vCont packets if multiprocess

Try to always send vCont packets and include the PID in them if running
multiprocess. This is necessary to ensure that with the upco

[lldb] [gdb-remote] Include PID in vCont packets if multiprocess

Try to always send vCont packets and include the PID in them if running
multiprocess. This is necessary to ensure that with the upcoming full
multiprocess support always resumes the correct process without having
to resort to the legacy Hc packets.

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

show more ...

Revert "[lldb] [gdb-remote] Include PID in vCont packets if multiprocess"

This reverts commit ccb9d4d4addc2fb2aa94cf776d43d8be35365272.

https://reviews.llvm.org/D131758

Differential Revision: http

Revert "[lldb] [gdb-remote] Include PID in vCont packets if multiprocess"

This reverts commit ccb9d4d4addc2fb2aa94cf776d43d8be35365272.

https://reviews.llvm.org/D131758

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

show more ...