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
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
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
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else. lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.
A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.
Re-landing this with a uuid_is_null() implementation added to
Utility/UuidCompatibility.h for non-Darwin systems.
Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
This reverts commit d8879fba8825b9799166ba0ea552d4027bfb8ad1.
Debian bot failure; I included <uuid/uuid.h> to get uuid_is_null() but
don't get it there. Will memcmp or whatever & recommit.
Add support to Mach-O corefiles and to live gdb remote serial protocol
connections for the corefile/remote stub to provide a list of load
addresses of binaries that should be found & loaded by lldb, and nothing
else. lldb will try to parse the binary out of memory, and if it can
find a UUID, try to find a binary & its debug information based on the
UUID, falling back to using the memory image if it must.
A bit of code unification from three parts of lldb that were loading
individual binaries already, so there is a shared method in
DynamicLoader to handle all of the variations they were doing.
Differential Revision: https://reviews.llvm.org/D130813
rdar://94249937
rdar://94249384
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
- 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
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
Don't overwrite the host architecture (obtained from qHostInfo) with the
process info (obtained from qProcessInfo).
Differential revision: https://reviews.llvm.org/D121442
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.
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve
the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
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
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
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
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
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
ReadExtFeature provides equivalent functionality. Also fix a but in
ReadExtFeature, which prevented it from being used for auxv data (it
contains nul characters).
We added some support for this mode back in 2015, but the feature was
never productionized. It is completely untested, and there are known
major structural lldb issues that need to be resolved before this
feature can really be supported.
It also complicates making further changes to stop reply packet
handling, which is what I am about to do.
Differential Revision: https://reviews.llvm.org/D110553
Add a llvm::Split() implementation that can be used via range-for loop,
e.g.:
for (StringRef x : llvm::Split("foo,bar,baz", ','))
...
The implementation uses an additional SplittingIterator class that
uses StringRef::split() internally.
Differential Revision: https://reviews.llvm.org/D110496
Replace the uses of StringConvert combined with hand-rolled array
splitting with llvm::StringRef.split() and llvm::to_integer().
Differential Revision: https://reviews.llvm.org/D110472
If the remote gdbserver's qfThreadInfo reply has a trailing comma,
GDBRemoteCommunicationClient::GetCurrentProcessAndThreadIDs will return
an empty vector of thread ids. This will cause lldb to recurse through
three functions trying to get the list of threads, until it blows its
stack and crashes.
A trailing comma is a malformed response, but it shouldn't cause lldb to
crash. This patch will return the tids received before the malformed
response.
Reviewed By: clayborg, labath
Differential Revision: https://reviews.llvm.org/D109937
Always send PID in the detach packet when multiprocess extensions are
enabled. This is required by qemu's GDB server, as plain 'D' packet
results in an error and the emulated system is not resumed.
Differential Revision: https://reviews.llvm.org/D110033
GDB uses normalized errno values for vFile errors. Implement
the translation between them and system errno values in the gdb-remote
plugin.
Differential Revision: https://reviews.llvm.org/D108148
Fall back to QEnvironmentHexEncoded if QEnvironment is not supported.
The latter packet is an LLDB extension, while the former is universally
supported.
Add tests for both QEnvironment and QEnvironmentHexEncoded packets,
including both use due to characters that need escaping and fallback
when QEnvironment is not supported.
Differential Revision: https://reviews.llvm.org/D108018
Implement the simpler vRun packet and prefer it over the A packet.
Unlike the latter, it tranmits command-line arguments without redundant
indices and lengths. This also improves GDB compatibility since modern
versions of gdbserver do not implement the A packet at all.
Make qLaunchSuccess not obligatory when using vRun. It is not
implemented by gdbserver, and since vRun returns the stop reason,
we can assume it to be successful.
Differential Revision: https://reviews.llvm.org/D107931
Add a GDB-compatible fallback to vFile:fstat for vFile:mode, and to
vFile:open for vFile:exists. Note that this is only partial fallback,
as it fails if the file cannot be opened.
Differential Revision: https://reviews.llvm.org/D107811
Implement a fallback to getting the file size via vFile:stat packet
when the remote server does not implement vFile:size. This makes it
possible to query file sizes from remote gdbserver.
Note that unlike vFile:size, the fallback will not work if the server is
unable to open the file.
While at it, add a few tests for the 'platform get-size' command.
Differential Revision: https://reviews.llvm.org/D107780
Report timeout exceeded and connection lost error messages
when sending the initial handshake packet in a gdb remote
serial protocol connection, an especially fragile time.
Differential Revision: https://reviews.llvm.org/D108888
Extend PluginManager::SaveCore() to support saving core dumps
via Process plugins. Implement the client-side part of qSaveCore
request in the gdb-remote plugin, that creates the core dump
on the remote host and then uses vFile packets to transfer it.
Differential Revision: https://reviews.llvm.org/D101329
Add a support for handling fork/vfork stops in LLGS client. At this
point, it only sends a detach packet for the newly forked child
(and implicitly resumes the parent).
Differential Revision: https://reviews.llvm.org/D100206
