Added a missing "break;" after seeing a clang warning about potential fall through annotation.

llvm-svn: 308776

Fixing Android builder

llvm-svn: 307773

Adding Support for Error Strings in Remote Packets

Summary:
This patch adds support for sending strings along with
error codes in the reply packets. The implementation is
based on the feedback recie

Adding Support for Error Strings in Remote Packets

Summary:
This patch adds support for sending strings along with
error codes in the reply packets. The implementation is
based on the feedback recieved in the lldb-dev mailing
list. The patch also adds an extra packet for the client
to query if the server has the capability to provide
strings along with error replys.

Reviewers: labath, jingham, sas, lldb-commits, clayborg

Reviewed By: labath, clayborg

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

llvm-svn: 307768

show more ...

Implementation of remote packets for Trace data.

Summary:
The changes consist of new packets for trace manipulation and
trace collection. The new packets are also documented. The packets
are capable

Implementation of remote packets for Trace data.

Summary:
The changes consist of new packets for trace manipulation and
trace collection. The new packets are also documented. The packets
are capable of providing custom trace specific parameters to start
tracing and also retrieve such configuration from the server.

Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner

Reviewed By: clayborg, labath

Subscribers: krytarowski, lldb-commits

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

llvm-svn: 303972

show more ...

iwyu fixes on lldbUtility.

This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). The goal here is to make sure that
a

iwyu fixes on lldbUtility.

This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). The goal here is to make sure that
all files include the exact set of headers which are needed
for that file only, to eliminate cases of dead includes (e.g.
someone deleted some code but forgot to delete the header
includes that that code necessitated), and to eliminate the
case where header includes are picked up transitively.

llvm-svn: 299676

show more ...

Implement QPassSignals GDB package in lldb-server

Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without

Implement QPassSignals GDB package in lldb-server

Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.

Reviewers: jmajors, labath

Subscribers: danalbert, srhines, emaste, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <[email protected]>

llvm-svn: 296101

show more ...

gdb-remote: Add jModulesInfo packet

Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant

gdb-remote: Add jModulesInfo packet

Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.

This decreases the attach time to an android application by about 40%.

Reviewers: clayborg

Subscribers: tberghammer, lldb-commits, danalbert

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

llvm-svn: 280919

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):

find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;

The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.

Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.

llvm-svn: 280751

show more ...

Remove some lldbassert's from the packet checking code.

Greg says he doesn't need these asserts anymore and since they cause occasional test suite
crashes, out they go.

llvm-svn: 268827

Fixed an issue that could cause debugserver to return two stop reply packets ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is run

Fixed an issue that could cause debugserver to return two stop reply packets ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling:

rnb_err_t
RNBRemote::HandlePacket_stop_process (const char *p)
{
if (!DNBProcessInterrupt(m_ctx.ProcessID()))
HandlePacket_last_signal (NULL);
return rnb_success;
}

In the call to DNBProcessInterrupt we did:

nub_bool_t
DNBProcessInterrupt(nub_process_t pid)
{
MachProcessSP procSP;
if (GetProcessSP (pid, procSP))
return procSP->Interrupt();
return false;
}

This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response.

To fix this I did the following:
1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines
2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen
3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets.
4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply.
5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response.
6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse()
7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process.

The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (incorrect extra stop reply packet)
--> c
<-- OK (response from z0 packet)

Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this:

--> \x03
<-- $T<stop reply 1>
--> z0,AAAAA,BB (set breakpoint)
<-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets)
<-- OK -- (we are back on track as this is a valid response to z0)
...

As time goes on we should add more packet validators.

<rdar://problem/22859505>

llvm-svn: 265086

show more ...

Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break.

llvm-svn: 261950

Modify "platform connect" to connect to processes as well

The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out)

Modify "platform connect" to connect to processes as well

The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.

The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.

Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.

This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.

Differential revision: http://reviews.llvm.org/D14952

llvm-svn: 255016

show more ...

lldb-server: add support for binary memory reads

Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it

lldb-server: add support for binary memory reads

Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it more compatible with the old $m packet. This allows
us to use almost the same code for handling both packet types. I have verified that debugserver
correctly handles $x packets even without the leading "0x". I have added a test which verifies
that the stub returns the same memory contents for both kinds of memory reads ($x and $m).

Reviewers: tberghammer, jasonmolenda

Subscribers: iancottrell, lldb-commits

Differential Revision: http://reviews.llvm.org/D13695

llvm-svn: 250295

show more ...

Fix jSignalsInfo packet handling.

llvm-svn: 243257

Add jThreadsInfo support to lldb-server

Summary:
This commit adds initial support for the jThreadsInfo packet to lldb-server. The current
implementation does not expedite inferior memory. I have al

Add jThreadsInfo support to lldb-server

Summary:
This commit adds initial support for the jThreadsInfo packet to lldb-server. The current
implementation does not expedite inferior memory. I have also added a description of the new
packet to our protocol documentation (mostly taken from Greg's earlier commit message).

Reviewers: clayborg, ovyalov, tberghammer

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D11187

llvm-svn: 242402

show more ...

Refactor Unix signals.

Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platf

Refactor Unix signals.

Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.

Reviewers: ovyalov, clayborg

Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits

Differential Revision: http://reviews.llvm.org/D11094

llvm-svn: 242101

show more ...

Fetch object file load address if it isn't specified by the linker

Differential revision: http://reviews.llvm.org/D10490

llvm-svn: 240052

Add support for the qEcho command to lldb-server in the common packets.

llvm-svn: 238533

Remote Non-Stop Support

Summary:

This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.

Non

Remote Non-Stop Support

Summary:

This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.

Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.

Handling of '%' async notification packets will be added next.

Reviewers: clayborg

Subscribers: lldb-commits, ADodds, ted, deepak2427

Differential Revision: http://reviews.llvm.org/D9656

llvm-svn: 237239

show more ...

Add qModuleInfo request in order to get module information (uuid, triple,..) by module path from remote platform.

http://reviews.llvm.org/D7709

llvm-svn: 230556

Add support for SBProcess::PutSTDIN to remote processes

Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.

This

Add support for SBProcess::PutSTDIN to remote processes

Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.

This allows processes using the API to pump stdin into a remote
inferior process.

It fixes a hang in TestProcessIO.py when running against a remote
target.

llvm-svn: 228419

show more ...

Fix the ability of "lldb-platform" to upload files.

The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If w

Fix the ability of "lldb-platform" to upload files.

The issue was GDBRemoteCommunication::CheckForPacket() already fixes up any prefixed bytes (0x7d followed by value that is XOR'ed with 0x20). If we do this again, we cause binary packets to lose bytes.

This allows lldb-platform to be able to upload binaries and debug them remotely.

llvm-svn: 218002

show more ...

Add lldb-gdbserver support for Linux x86_64.

This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).

Not every debugserver option is covered yet

Add lldb-gdbserver support for Linux x86_64.

This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).

Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.

The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64

Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id [email protected]). I switched over to
user [email protected] in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.

llvm-svn: 212069

show more ...

Added an option to turn OFF the "detach on error" behavior that was added
to debugserver when launching processes.

<rdar://problem/16216199>

llvm-svn: 211658

Extends StringExtractorGDBRemote to support debugger packets.

CC: lldb-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2337

llvm-svn: 196525