[lldb] [gdb-remote] Refactor killing process and move it to client

Refactor the code responsible for sending the "k" packet and move it
into GDBRemoteCommunicationClient::KillProcess() method. This

[lldb] [gdb-remote] Refactor killing process and move it to client

Refactor the code responsible for sending the "k" packet and move it
into GDBRemoteCommunicationClient::KillProcess() method. This is part
of refactoring to enable multiprocess support in the client,
and to support using the vKill packet instead.

As part of the refactoring, the following functional changes apply:

- Some redundant logging has been removed, as any failures are returned
via exit_string anyway.

- SetLastStopPacket() is no longer called. It is used only to populate
the thread list, and since the process has just exited and we're
terminating the process instance, there's really no reason to set it.

- On successful kill, exit_string is set to "killed", to clearly
indicate that the process has terminated on our request rather than
on its own.

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

show more ...

Use has_value instead of hasValue (NFC)

[lld] Don't use Optional::hasValue (NFC)

This patch replaces x.hasValue() with x where x is contextually
convertible to bool.

Revert "Don't use Optional::hasValue (NFC)"

This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.

Don't use Optional::hasValue (NFC)

Don't use Optional::getValue (NFC)

[trace][intelpt] Support system-wide tracing [13] - Add context switch decoding

- Add the logic that parses all cpu context switch traces and produces blocks of continuous executions, which will be

[trace][intelpt] Support system-wide tracing [13] - Add context switch decoding

- Add the logic that parses all cpu context switch traces and produces blocks of continuous executions, which will be later used to assign intel pt subtraces to threads and to identify gaps. This logic can also identify if the context switch trace is malformed.
- The continuous executions blocks are able to indicate when there were some contention issues when producing the context switch trace. See the inline comments for more information.
- Update the 'dump info' command to show information and stats related to the multicore decoding flow, including timing about context switch decoding.
- Add the logic to conver nanoseconds to TSCs.
- Fix a bug when returning the context switches. Now they data returned makes sense and even empty traces can be returned from lldb-server.
- Finish the necessary bits for loading and saving a multi-core trace bundle from disk.
- Change some size_t to uint64_t for compatibility with 32 bit systems.

Tested by saving a trace session of a program that sleeps 100 times, it was able to produce the following 'dump info' text:

```
(lldb) trace load /tmp/trace3/trace.json (lldb) thread trace dump info Trace technology: intel-pt

thread #1: tid = 4192415
Total number of instructions: 1

Memory usage:
Total approximate memory usage (excluding raw trace): 2.51 KiB
Average memory usage per instruction (excluding raw trace): 2573.00 bytes

Timing for this thread:

Timing for global tasks:
Context switch trace decoding: 0.00s

Events:
Number of instructions with events: 0
Number of individual events: 0

Multi-core decoding:
Total number of continuous executions found: 2499
Number of continuous executions for this thread: 102

Errors:
Number of TSC decoding errors: 0
```

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

show more ...

[lldb/gdb-remote] Fix -Wswitch after D116462

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
mem

[lldb] Refactor DataBuffer so we can map files as read-only

Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

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

show more ...

NFC. Fixing warnings from adding DXContainer

Adds DXContainer to switch statements in Clang and LLDB to silence
warnings.

[lldb] Don't overwrite the host arch with the process arch

Don't overwrite the host architecture (obtained from qHostInfo) with the
process info (obtained from qProcessInfo).

Differential revision:

[lldb] Don't overwrite the host arch with the process arch

Don't overwrite the host architecture (obtained from qHostInfo) with the
process info (obtained from qProcessInfo).

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

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] Convert ProcessGDBRemoteLog to the new API

[lldb] [gdb-remote] Support getting siginfo via API

Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.

Differential Revision: https://reviews.llv

[lldb] [gdb-remote] Support getting siginfo via API

Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.

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

show more ...

Revert "[lldb] [gdb-remote] Support getting siginfo via API"

This reverts commit 1a8f60f5f5b8638a3e8e7fb31ba7ae9e17a7ff2d.
The API requires further work.

[lldb] [gdb-remote] Support getting siginfo via API

Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.

Differential Revision: https://reviews.llv

[lldb] [gdb-remote] Support getting siginfo via API

Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.

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

show more ...

Load binary by UUID from qProcessInfo packet fields

Support three new keys in the qProcessInfo response from the remote
gdb stub to handle the case of attaching to a core running some type
of standa

Load binary by UUID from qProcessInfo packet fields

Support three new keys in the qProcessInfo response from the remote
gdb stub to handle the case of attaching to a core running some type
of standalone/firmware code and the stub knows the UUID and load
address-or-slide for the binary. There will be no proper DynamicLoader
plugin in this scenario, but we can try to locate and load the binary
into lldb at the correct offset.

Differential Revision: https://reviews.llvm.org/D116211
rdar://75191077

show more ...

[lldb/gdb-remote] Remove initial pipe-draining workaround

This code, added in rL197579 (Dec 2013) is supposed to work around what
was presumably a qemu bug, where it would send unsolicited stop-repl

[lldb/gdb-remote] Remove initial pipe-draining workaround

This code, added in rL197579 (Dec 2013) is supposed to work around what
was presumably a qemu bug, where it would send unsolicited stop-reply
packets after the initial connection.

At present, qemu does not exhibit such behavior. Also, the 10ms delay
introduced by this code is sufficient to mask bugs in other stubs, but
it is not sufficient to *reliably* mask those bugs. This resulted in
flakyness in one of our stubs, which was (incorrectly) sending a +
packet at the start of the connection, resulting in a small-but-annoying
number of dropped connections.

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

show more ...

[lldb] Support gdbserver signals

GDB and LLDB use different signal models. GDB uses a predefined set
of signal codes, and maps platform's signos to them. On the other hand,
LLDB has historically s

[lldb] Support gdbserver signals

GDB and LLDB use different signal models. GDB uses a predefined set
of signal codes, and maps platform's signos to them. On the other hand,
LLDB has historically simply passed native signos.

In order to improve compatibility between LLDB and gdbserver, the GDB
signal model should be used. However, GDB does not provide a mapping
for all existing signals on Linux and unsupported signals are passed
as 'unknown'. Limiting LLDB to this behavior could be considered
a regression.

To get the best of both worlds, use the LLDB signal model when talking
to lldb-server, and the GDB signal model otherwise. For this purpose,
new versions of lldb-server indicate "native-signals+" via qSupported.
At the same time, we also detect older versions of lldb-server
via QThreadSuffixSupported for backwards compatibility. If neither test
succeeds, we assume gdbserver or another implementation using GDB model.

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

show more ...

[lldb] Use std::string instead of llvm::Twine in GDBRemoteCommunicationClient

From the documentation:

A Twine is not intended for use directly and should not be stored, its
implementation relie

[lldb] Use std::string instead of llvm::Twine in GDBRemoteCommunicationClient

From the documentation:

A Twine is not intended for use directly and should not be stored, its
implementation relies on the ability to store pointers to temporary
stack objects which may be deallocated at the end of a statement.
Twines should only be used accepted as const references in arguments,
when an API wishes to accept possibly-concatenated strings.

rdar://84799118

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

show more ...

Modernize Platform::GetOSKernelDescription

[lldb] Modernize Platform::GetOSBuildString

Use StringRef::contains (NFC)

[llvm] [ADT] Update llvm::Split() per Pavel Labath's suggestions

Optimize the iterator comparison logic to compare Current.data()
pointers. Use std::tie for assignments from std::pair. Replace
the

[llvm] [ADT] Update llvm::Split() per Pavel Labath's suggestions

Optimize the iterator comparison logic to compare Current.data()
pointers. Use std::tie for assignments from std::pair. Replace
the custom class with a function returning iterator_range.

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

show more ...