[lldb] [client] Support for multiprocess extension

Add a minimal support for the multiprocess extension in gdb-remote
client. It accepts PIDs as part of thread-ids, and rejects PIDs that
do not mat

[lldb] [client] Support for multiprocess extension

Add a minimal support for the multiprocess extension in gdb-remote
client. It accepts PIDs as part of thread-ids, and rejects PIDs that
do not match the current inferior.

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

show more ...

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I

[trace][intel-pt] Implement trace start and trace stop

This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.

There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:

- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests

I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.

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

show more ...

[lldb] Apply gdb-remote timeout to platform connections as well

We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait b

[lldb] Apply gdb-remote timeout to platform connections as well

We have a plugin.process.gdb-remote.packet-timeout setting, which can be
used to control how long the lldb client is willing to wait before
declaring the server side dead. Our test suite makes use of this
feature, and sets the setting value fairly high, as the low default
value can cause flaky tests, particularly on slower bots.

After fixing TestPlatformConnect (one of the few tests exercising the
remote platform capabilities of lldb) in 4b284b9ca, it immediately
started being flaky on the arm bots. It turns out this is because the
packet-timeout setting is not being applied to platform connections.

This patch makes the platform connections also respect the value of this
setting. It also adds a test which checks that the timeout value is
being honored.

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

show more ...

Use remote regnums in expedited list, value regs and invalidate regs

Native register descriptions in LLDB specify lldb register numbers in
value_regs and invalidate_regs lists. These register number

Use remote regnums in expedited list, value regs and invalidate regs

Native register descriptions in LLDB specify lldb register numbers in
value_regs and invalidate_regs lists. These register numbers may not
match with Process gdb-remote register numbers which are generated by
native process after counting all registers in its register sets.

It was coincidentally not causing any problems as we never came across
a native target with dynamically changing register sets and register
numbers generated by counter matched with LLDB native register numbers.
This came up while testing target AArch64 SVE which can choose register
sets based on underlying hardware.

This patch fixes this behavior and always tries to use remote register
numbers while reading/writing registers over gdb-remote protocol.

Reviewed By: labath

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

show more ...

[ThreadPlan] fix exec on Linux

[LLDB] Add support to resize SVE registers at run-time

This patch builds on previously submitted SVE patches regarding expedited
register set and per thread register infos. (D82853 D82855 and D82857

[LLDB] Add support to resize SVE registers at run-time

This patch builds on previously submitted SVE patches regarding expedited
register set and per thread register infos. (D82853 D82855 and D82857)

We need to resize SVE register based on value received in expedited list.
Also we need to resize SVE registers when we write vg register using
register write vg command. The resize will result in a updated offset
for all of fpr and sve register set. This offset will be configured
in native register context by RegisterInfoInterface and will also be
be updated on client side in GDBRemoteRegisterContext.

A follow up patch will provide a API test to verify this change.

Reviewed By: labath

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

show more ...

[LLDB] Add per-thread register infos shared pointer in gdb-remote

In gdb-remote process we have register infos defind as a refernce object of
GDBRemoteDynamicRegisterInfo class. In past register inf

[LLDB] Add per-thread register infos shared pointer in gdb-remote

In gdb-remote process we have register infos defind as a refernce object of
GDBRemoteDynamicRegisterInfo class. In past register infos have remained
constant througout the life time of a process.

This has changed after AArch64 SVE support where register infos will have
per-thread configuration. SVE registers will have per-thread size and can
be updated while running. This patch aims to build up for that support by
changing GDBRemoteDynamicRegisterInfo reference to a shared pointer deinfed
per-thread.

Reviewed By: labath

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

show more ...

Make offset field optional in RegisterInfo packet for Arm64

This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new fu

Make offset field optional in RegisterInfo packet for Arm64

This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.

As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.

This committ also includes a test to verify all of above functionality
on Arm64.

Reviewed By: labath

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

show more ...

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

[intel-pt][trace] Implement a "get supported trace type" packet

Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology

[intel-pt][trace] Implement a "get supported trace type" packet

Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type

thread trace start

to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.

Also, if the user typed

help thread trace start

We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.

I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got

$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}

On a machine without intel-pt support, I got

$ process plugin packet send "jTraceSupportedType"
packet: jTraceSupportedType
response: E00;

Reviewed By: clayborg, labath

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

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] Modernize PseudoTerminal::OpenFirstAvailablePrimary

replace char*+length combo with llvm::Error

[lldb] Check for and use ptsname_r if available

ptsname is not thread-safe. ptsname_r is available on most (but not all)
systems -- use it preferentially.

In the patch I also improve the thread-saf

[lldb] Check for and use ptsname_r if available

ptsname is not thread-safe. ptsname_r is available on most (but not all)
systems -- use it preferentially.

In the patch I also improve the thread-safety of the ptsname fallback
path by wrapping it in a mutex. This should guarantee the safety of a
typical ptsname implementation using a single static buffer, as long as
all callers go through this function.

I also remove the error arguments, as the only way this function can
fail is if the "primary" fd is not valid. This is a programmer error as
this requirement is documented, and all callers ensure that is the case.

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

show more ...

[lldb] Don't use hardware index to determine whether a breakpoint site is hardware

Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine thi

[lldb] Don't use hardware index to determine whether a breakpoint site is hardware

Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine this index.

This patch makes StoppointLocation::IsHardware pure virtual and lets BreakpointSite
override it using more accurate BreakpointSite::Type.

It also adds assertions to be sure that a breakpoint site is hardware when this is required.

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

show more ...

[lldb] Remove unused argument (NFC)

Nobody is writing to the stream so there's no point in passing it
around.

[ProcessGDBRemote] Get rid of an unused function.

The define was wrong. I could've fixed it, but given this is
unused I decided to drop the function altogether.

[ProcessGDBRemote] Fix a typo in an ifdef from 58de2a3851391d

[ProcessGDBRemote] Placate the Windows buildbot.

I'm probably going to rewrite this function anyway, but, in
the meanwhile.

[Apple Silicon] Initial support for Rosetta

Translated processes talk with a different debugserver, shipped with
macOS 11. This patch detects whether a process is translated and
attaches to the corr

[Apple Silicon] Initial support for Rosetta

Translated processes talk with a different debugserver, shipped with
macOS 11. This patch detects whether a process is translated and
attaches to the correct debugserver implementation.
It's the first patch of a series. Tested on the lldb test suite.

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

show more ...

[lldb] Rename Master/Slave to Primary/Secondary (NFC)

[lldb/Reproducers] Move connection logic into replay server (NFC)

Move the logic for connecting to the replay server into the replay
server itself, so it can be reused outside of ProcessGDBRemote.

[lldb/Reproducers] Make DoConnectRemote connect to the replay server.

All entry points into ProcessGDBRemote that connect to the debug server
should connect to the replay server instead during repro

[lldb/Reproducers] Make DoConnectRemote connect to the replay server.

All entry points into ProcessGDBRemote that connect to the debug server
should connect to the replay server instead during reproducer replay.
This patch adds the necessary logic for ConnectRemote, which is
accessible from the SB API. This fixes active replay for
TestRecognizeBreakpoint.py as described in D78588.

show more ...

[lldb] NFC: Fix trivial typo in comments, documents, and messages

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

[lldb] Change Communication::SetConnection to take a unique_ptr

The function takes ownership of the object. This makes that explicit,
and avoids unowned pointers floating around.

Replace std::string::find == 0 with StringRef::startswith

This is both more readable and faster. Found by clang-tidy's
abseil-string-find-startswith.