os to "ios" or "macosx" if it is unspecified. For environments
where there genuinely is no os, we don't want to errantly
convert that to ios/macosx, e.g. bare board debugging.
Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and
PlatformRemoteAppleTV to not create themselves if we have
an unspecified OS. Same problem - these are not appropriate
platforms for bare board debugging environments.
Have Process::Attach's logging take place if either
process or target logging is enabled.
<rdar://problem/25592378>
llvm-svn: 265732
In turns out this does make a functional change, in case when the inferior hits an int3 that was
not placed by the debugger. Backing out for now.
llvm-svn: 265647
Summary:
SetThreadStopInfo was checking for a breakpoint at the current PC several times. This merges the
identical code into a separate function. I've left one breakpoint check alone, as it was doing
more complicated stuff, and it did not see a way to merge that without making the interface
complicated. NFC.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18819
llvm-svn: 265560
Summary:
This resolves a similar problem as D16720 (which handled the case when we single-step onto a
breakpoint), but this one deals with involutary stops: when we stop a thread (e.g. because
another thread has hit a breakpont and we are doing a full stop), we can end up stopping it right
before it executes a breakpoint instruction. In this case, the stop reason will be empty, but we
will still step over the breakpoint when do the next resume, thereby missing a breakpoint hit.
I have observed this happening in TestConcurrentEvents, but I have no idea how to reproduce this
behavior more reliably.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18692
llvm-svn: 265525
Summary:
The logic to read modules from memory was added to LoadModuleAtAddress
in the dynamic loader, but not in process gdb remote. This means that when
the remote uses svr4 packets to give library info, libraries only present
on the remote will not be loaded.
This patch therefore involves some code duplication from LoadModuleAtAddress
in the dynamic loader, but removing this would require some amount of code
refactoring.
Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted
Subscribers: tfiala, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18531
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265418
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
to each other. This should remove some infrequent teardown crashes when the
listener is not the debugger's listener.
Processes now need to take a ListenerSP, not a Listener&.
This required changing over the Process plugin class constructors to take a ListenerSP, instead
of a Listener&. Other than that there should be no functional change.
<rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39
llvm-svn: 262863
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
Summary:
r259344 introduced a bug, where we fail to perform a single step, when the instruction we are
stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem
and add a test case.
Reviewers: tberghammer, emaste
Subscribers: abhishek.aggarwal, lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D16767
llvm-svn: 259488
Summary:
- The patch solves Bug 23478 and Bug 19311. Resolving
Bug 23478 also resolves Bug 23039.
Correct ThreadStopInfo is set for Linux and FreeBSD
platforms.
- Summary:
When a trace event is reported, we need to check
whether the trace event lands at a breakpoint site.
If it lands at a breakpoint site then set the thread's
StopInfo with the reason 'breakpoint'. Else, set the reason
to be 'Trace'.
Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov
Subscribers: emaste
Differential Revision: http://reviews.llvm.org/D16720
llvm-svn: 259344
This is a packet which allows the remote gdb stub to ask for the address
of a symbol in the process. lldb sends the packet (offering to provide
addresses for symbol names) after every solib loaded. I changed lldb so
that once the stub has indicated that it doesn't need any more symbol
addresses, lldb will stop sending the qSymbol:: packet on new solib loads.
This can yield a performance benefit over slower communication links when
there are many solibs involved.
<rdar://problem/23310049>
llvm-svn: 257569
Summary:
Allows the remote to enumerate the link map when adding and removing
shared libraries, so that lldb doesn't need to read it manually from
the remote's memory.
This provides very large speedups (on the order of 50%) in total
startup time when using the ds2 remote on android or Tizen devices.
Reviewers: ADodds, tberghammer, tfiala
Subscribers: tberghammer, sas, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16004
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257502
at each public stop to improve performance a bit. Most of the
information lldb needed was already in the jThreadsInfo response;
complete that information and catch a few cases where we could still
fall back to getting the information via discrete memory reads.
debugserver adds 'associated_with_dispatch_queue' and 'dispatch_queue_t
keys to the jThreadsInfo response for all the threads. lldb needs the
dispatch_queue_t value. And associated_with_dispatch_queue helps to
identify which threads definitively don't have any queue information so
lldb doesn't try to do memory reads to get that information just because
it was absent in the jThreadsInfo response.
Remove the queue information from the questionmark (T) packet. We'll
get the information for all threads via the jThreadsInfo response -
sending the information for the stopping thread (on all the private
stops, plus the less frequent public stop) was unnecessary information
being sent over the wire.
SystemRuntimeMacOSX will try to get information about queues by asking
the Threads for them, instead of reading memory.
ProcessGDBRemote changes to recognize the new keys being sent in the
jThreadsInfo response. Changes to ThreadGDBRemote to track the new
information. Also, when a thread is marked as definitively not
associated with a libdispatch queue, don't fall back to the system
runtime to try memory reads to find the queue name / kind / ID etc.
<rdar://problem/23309359>
llvm-svn: 257453
"qserial" to "qserialnum" because "qserial" looks a lot like the
queue type (either 'serial' or 'concurrent') and can be confusing
to read through. debugserver passes these up either in the questionmark
("T") packet, or in the response to the jThreadsInfo packet.
llvm-svn: 257121
Summary:
Some debug servers don't support it so there's no point in spamming
this.
Reviewers: clayborg
Subscribers: fjricci, lldb-commits
Differential Revision: http://reviews.llvm.org/D15972
llvm-svn: 257116
(There are changes in the copies of these four files in the FreeBSD base
system, and I've changed these ones to reduce gratuitous diffs in future
imports.)
llvm-svn: 256723
"thread-pcs" key is added to the T (questionmark) packet in
gdb-remote protocol so that lldb doesn't need to query the
pc values of every thread before it resumes a process.
The only odd part with this is that I'm sending the pc
values in big endian order, so we need to know the endianness
of the remote process before we can use them. All other
register values in gdb-remote protocol are sent in native-endian
format so this requirement doesn't exist. This addition is a
performance enhancement -- lldb will fall back to querying the
pc of each thread individually if it needs to -- so when
we don't have the byte order for the process yet, we don't
use these values. Practically speaking, the only way I've
been able to elicit this condition is for the first
T packet when we attach to a process.
<rdar://problem/21963031>
llvm-svn: 255942
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
* Add support for representing signed integers
* Add new constructors taking any signed or unsigned integer types
Differential revision: http://reviews.llvm.org/D15187
llvm-svn: 254715
Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the stop-reply packet). Normally, this should not happen
(the process cannot generate output when it is stopped), but due to the fact that pty
communication is asynchronous in the linux kernel (llvm.org/pr25652), we may sometimes get this
output too late. Instead, we just hold the output, and send it next time we resume. This is not
ideal, but at least it makes sure we do not violate the remote protocol. Given that this happens
extremely rarely it's not worth trying to work around it with sleeps or something like that.
I also remove the m_stdio_communication_mutex, as all of LLGS is now single-threaded anyway.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15019
llvm-svn: 254200
They get treated as special RLE encoding symbols and packets get
corrupted. Most other packet types already know about this apparently,
but QEnvironment missed these two.
Should fix PR25300.
llvm-svn: 252521
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
Summary:
Gdb-remote's async thread sent out the eBroadcastBitRunPacketSent message *before* actually
sending out the continue packet. Since it's this message the actually triggers the public state
transition, it could happen (and it did happen in TestAttachResume, which does an "process
interrupt" right after a continue) that we attempt to stop the inferior before it was actually
started (which obviously did not end well). This fixes the problem by moving the broadcast after
the packet was actually sent.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14083
llvm-svn: 251399
This avoids the need to query the PC for private resume operations (public resumes have the PC
from the bigger jStopInfo packet) and speeds up the stepping on an android target by about 10%
(it some cases even more).
llvm-svn: 251301
This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find debugserver inside the selected Xcode.app on your system.
<rdar://problem/23167253>
llvm-svn: 250735
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
disabled the use of the jThreadGetExtendedInfo packet which is used
to retrieve additional information about a thread, such as the QoS
setting for that thread on darwin systems.
Re-enable the use of the jThreadGetExtendedInfo packet, and add
some quick tests to the TestQueues mac test case which will verify
that we can retrieve the QoS names for these test threads.
<rdar://problem/22925096>
llvm-svn: 250364
Most platforms have "/dev/null". Windows has "nul". Instead of
hardcoding the string /dev/null at various places, make a constant
that contains the correct value depending on the platform, and use
that everywhere instead.
llvm-svn: 250331
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
on iOS devices; fallout from Vince's cleanups made
in r237218 back in May. iOS native lldbs will call
StartDebugserverProcess() with a random port #
(see ProcessGDBRemote::LaunchAndConnectToDebugserver)
and neither side of this conditional expression should
be followed in that case.
I added an "if (in_port == 0) { ..." check around the
entire if/then/else and indented the block of code so
the diff looks larger than it really is.
<rdar://problem/21712643>
llvm-svn: 248343
Character with ASCII code 0 is incorrectly treated by LLDB as the end of
RSP packet. The left of the debugger server output is silently ignored.
Patch from evgeny.leviant@gmail.com
Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12523
llvm-svn: 247908
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
SUMMARY:
Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion
on this topic. Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC,
qfThreadInfo, Hg and Hc packets. Reply from ? packet is as simple as S05. There is no
packet which gives us process or threads information. In such cases, assume pid=tid=1.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D12876
llvm-svn: 247773
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
qXfer:features:read:target.xml packet, or via the
plugin.process.gdb-remote.target-definition-file setting, if the
register definition doesn't give us eh_frame or DWARF register
numbers for that register, try to get that information from the ABI
plugin.
The DWARF/eh_frame register numbers are defined in the ABI
standardization documents - so getting this from the ABI plugin is
reasonable. There's little value in having the remote stub inform
us of this generic information, as long as we can all agree on the
names of the registers.
There's some additional information we could get from the ABI. For
instance, on ABIs where function arguments are passed in registers,
lldb defines alternate names like "arg1", "arg2", "arg3" for these
registers so they can be referred to that way by the user. We could
get this from the ABI if the remote stub doesn't provide that. That
may be something worth doing in the future - but for now, I'm keeping
this a little more minimal.
Thinking about this, what we want/need from the remote stub at a
minimum are:
1. The names of the register
2. The number that the stub will use to refer to the register with
the p/P packets and in the ? response packets (T/S) where
expedited register values are provided
3. The size of the register in bytes
(nice to have, to remove any doubt)
4. The offset of the register in the g/G packet if we're going to
use that for reading/writing registers.
debugserver traditionally provides a lot more information in
addition to this via the qRegisterInfo packet, and debugserver
augments its response to the qXfer:features:read:target.xml
query to include this information. Including:
DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754,
Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*,
float), registers that should be marked as invalid if this
register is modified, and registers that contain this register.
We might want to get all of this from the ABI - I'm not convinced
that it makes sense for the remote stub to provide any of these
details, as long as the ABI and remote stub can agree on register
names.
Anyway, start with eh_frame and DWARF coming from the ABI if
they're not provided by the remote stub. We can look at doing
more in the future.
<rdar://problem/22566585>
llvm-svn: 247121
When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-hex encoding so we don't
dump random 8-bit characters into the packet log.
I'm changing this check to allow whitespace characters
(newlines, linefeeds, tabs) to be printed if those are
the only non-printable characters in the packet.
This is primarily to get the response to the
qXfer:features:read:target.xml packet to show up in the
packet logs in human readable form. Right now we just
get a dozen kilobytes of hex-ascii and it's hard to
figure out what register number scheme is being used.
llvm-svn: 247120
Summary:
There was a race condition in the AsyncThread, where we would end up sending a vAttach
notification to the thread before it got a chance set up its listener (this can be reproduced by
adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then
get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the
ProcessGDBRemote constructor.
This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from
TestAttachResume, and will watch the buildbots for signs of trouble.
Reviewers: clayborg, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12552
llvm-svn: 246756
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
code that looks for a second stop-reply packet in response to an
interrupt (control-c). This is to handle the case where where a
stop packet is making its way up to lldb right as lldb decides to
interrupt the inferior. If the inferior is running and we interrupt
it, we'd expect a T11 type response meaning that the inferior halted
because of the interrupt. But if the interrupt gets a T05 type
response instead, meaning that we stopped execution by hitting a
breakpoint or whatever, then the interrupt was received while the
inferior was already paused and so it is treated as a "?" packet
-- the remote stub will send the stop message a second time.
There's a timeout where we wait to get this second stop reply packet
in SendContinuePacketAndWaitForResponse, currently 1ms. For a slow
remote target, it may take longer than that to send the second stop
reply packet. If that happens, then lldb will use that second stop
reply packet as the response for the next packet request it makes
to the remote stub. The two will be out of sync by one packet for
the rest of the debug session and it's going to go badly from then on.
I've seen times as slow as 46ms, and given the severity of missing that
second stop reply packet, I'm increasing the timeout to 100ms, or 0.1sec.
<rdar://problem/21990791>
llvm-svn: 246004
http://reviews.llvm.org/D9703
This updated patches correct problems in arm hardware watchpoint support patch posted earlier.
This patch has been tested on samsung chromebook (ARM - Linux) and PandaBoard using basic watchpoint test application.
Also it was tested on Nexus 7 Android device.
On chromebook linux we are able to set and clear all types of watchpoints but on android we end up getting a watchpoint packet error because we are not able to call hardware watchpoint ptrace functions successfully.
llvm-svn: 245961
Summary:
When a windows remote stops because of a DLL load/unload, the debug server
sends a stop reply packet that contains a `library` key with any value (usually
just `library:1`). This indicates to the debugger that a library has been
loaded or unloaded and that the list of libraries should be refreshed (usually
with `qXfer:libraries:read`).
This change just triggers a call to `LoadModules()` which in turns will send a
remote library read command when a stop reply that requests it is received.
Reviewers: clayborg, zturner, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12218
llvm-svn: 245708
This was breaking disassembly for arm machines that we force to be
thumb mode all the time because we were only checking for llvm::Triple::arm.
i.e.
armv6m (ARM Cortex-M0)
armv7m (ARM Cortex-M3)
armv7em (ARM Cortex-M4)
<rdar://problem/22334522>
llvm-svn: 245645
Summary:
This is useful when dealing with Windows remote that use only the
qXfer:libraries command which returns absolute base addresses, as
opposed to qXfer:libraries-svr4 which returns relative offsets for
module bases.
Reviewers: clayborg, zturner, ADodds
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12204
llvm-svn: 245625
Summary: Size specifier should come after `%` not before.
Reviewers: clayborg, ADodds
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12203
llvm-svn: 245608
to the user. e.g. specified via the
plugin.process.gdb-remote.target-definition-file
setting. Currently we silently ignore the target definition if
there is a parse error.
llvm-svn: 245536
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.
lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.
lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.
There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.
This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.
lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.
In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.
I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.
Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.
The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.
llvm-svn: 245141
SUMMARY:
The patch uses qfThreadID to get the thread IDs if qC packet is not supported by target.
Reviewers: jingham, clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D11519
llvm-svn: 244866
SUMMARY:
The patch supports TAAwatch:addr packet. The patch also sets m_watchpoints_trigger_after_instruction
to eLazyBoolNo when qHostInfo or qWatchpointSupportInfo is not supported by the target.
Reviewers: jingham, clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D11747
llvm-svn: 244865
SUMMARY:
Last 3bits of the watchpoint address are masked by the kernel. For example, n is
at 0x120010d00 and m is 0x120010d04. When a watchpoint is set at m, then watch
exception is generated even when n is read/written. To handle this case, instruction
at PC is emulated to find the base address of the load/store instruction. This address
is then appended to the description of the stop-info packet. Client then reads this
information to check whether the user has set a watchpoint on this address.
Reviewers: jingham, clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D11672
llvm-svn: 244864
The issue was we were sending a "qSymbol::" packet and it we were already disconnected were weren't exiting the while loop if we didn't successfully send the qSymbol packet.
<rdar://problem/22098746>
llvm-svn: 244683
working with (the Communication m_bytes ivar) contained a single packet.
Instead, it may contain multitudes. Find the boundaries of the first packet
in the buffer and replace that with the decompressed version leaving the
rest of the buffer unmodified.
<rdar://problem/21841377>
llvm-svn: 243846
Previously embedded interpreters were handled as ad-hoc source
files compiled into source/Interpreter. This made it hard to
disable a specific interpreter, or to add support for other
interpreters and allow the developer to choose which interpreter(s)
were enabled for a particular build.
This patch converts script interpreters over to a plugin-based system.
Script interpreters now live in source/Plugins/ScriptInterpreter, and
the canonical LLDB interpreter, ScriptInterpreterPython, is moved there
as well.
Any new code interfacing with the Python C API must live in this location
from here on out. Additionally, generic code should never need to
reference or make assumptions about the presence of a specific interpreter
going forward.
Differential Revision: http://reviews.llvm.org/D11431
Reviewed By: Greg Clayton
llvm-svn: 243681
Summary:
If we used unnamed pipes instead of named pipes, we can avoid having the
file system littered with debugserver-named-pipes if lldb-server happens to
crash for whatever reason. Also, on some buggy systems, it's possible to be
able to create but not to delete a fifo. Ideally, support for unnamed pipes
should be added to debugserver as well, so we can avoid the `#ifdef` here.
Reviewers: clayborg, vharron, chying
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11609
llvm-svn: 243667
Summary:
This commit moves the m_spawned_pids member from the common LLGS/Platform class to the plaform
specific part. This enables us to remove LLGS code, which was attempting to manage the
m_spawned_pids contents, but at the same time making sure, there is only one debugged process. If
we ever want to do multi-process debugging, we will probably want to replace this with a set of
NativeProcessProtocolSP anyway. The only functional change is that support for
qKillSpawnedProcess packet is removed from LLGS, but this was not used there anyway (we have the
k packet for that).
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11557
llvm-svn: 243513
system, make a couple of additional checks to see if the
attach was denied via the System Integrity Protection that
is new in Mac OS X 10.11. If so, return a special E87
error code to indicate this to lldb.
Up in lldb, if we receive the E87 error code, be specific
about why the attach failed.
Also detect the more common case of general attach failure
and print a better error message than "lost connection".
I believe this code will all build on Mac OS X 10.10 systems.
It may not compile or run on earlier versions of the OS.
None of this should build on other non-darwin systems.
llvm-svn: 243511
Summary:
Handle_k was printing an error when killing a process because KillSpawnedProcess was expecting to
be asynchronously notified of the process death, which no longer works, since we don't wait for
the process on a separate thread. However, the whole usage of KillSpawnedProcess is dubious here,
since it tries to be nice and terminate the process first with SIGTERM, which will not have the
intended effect on a ptraced process. I replace this code with a call to
NativeProcessProtocol::Kill, which does not suffer from these problems.
Reviewers: chaoren, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11520
llvm-svn: 243397
SUMMARY:
This patch fixes couple of issues:
1. A thread tries to lock a mutex which is already locked.
2. Updating a thread list before the stop packet is parsed so that it can get a valid thread id and allows to set the stop info correctly.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits
Differential Revision: http://reviews.llvm.org/D11449
llvm-svn: 243091
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
Summary:
This adds support for jstopinfo field of stop-reply packets. This field enables us to avoid
querying full thread stop data on most stops (see r242593 for more details).
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11415
llvm-svn: 242997
Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.
Reviewers: ovyalov, clayborg, tberghammer, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11150
This is a resubmission of r242305 after it was reverted due to bad interactions with the stdio
thread.
llvm-svn: 242783
Summary:
This commit removes the stdio forwarding thread in lldb-server in favor of a MainLoop callback.
As in some situations we need to forcibly flush the stream ( => Read() is called from multiple
places) and we still have multiple threads, I have had to additionally protect the communication
instance with a mutex.
Reviewers: ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11296
llvm-svn: 242782
Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread.
Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops.
llvm-svn: 242593
Summary:
It seems that reading of register data is the biggest bottleneck in LLGS at the moment. Sending
four registers instead of the full GPR set increases the jThreadsInfo processing time about
6-fold. Until we figure out where is this time going, this commit limits the amount of data we
send to provide a more fluid debugging experience.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11264
llvm-svn: 242517
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
This allows stepping operations that don't ever do a public stop to get all the info they need without having to send a jThreadsInfo packet since those tend to be large.
This patch will be followed by a patch that will detect when we do a public stop, and when that happens we will send a jThreadsInfo packet at that time to get all expedited registers and memory.
llvm-svn: 242352
Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.
Reviewers: ovyalov, clayborg, tberghammer, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11150
llvm-svn: 242305
should send when detaching and leaving the remote process/system
halted. Previously only the 'D' initial char was sent, which
resumed the process like a normal detach.
llvm-svn: 242256
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
Summary:
This is the first part of our effort to make llgs single threaded. Currently, llgs consists of
about three threads and the synchronisation between them is a major source of latency when
debugging linux and android applications.
In order to be able to go single threaded, we must have the ability to listen for events from
multiple sources (primarily, client commands coming over the network and debug events from the
inferior) and perform necessary actions. For this reason I introduce the concept of a MainLoop.
A main loop has the ability to register callback's which will be invoked upon receipt of certain
events. MainLoopPosix has the ability to listen for file descriptors and signals.
For the moment, I have merely made the GDBRemoteCommunicationServerLLGS class use MainLoop
instead of waiting on the network socket directly, but the other threads still remain. In the
followup patches I indend to migrate NativeProcessLinux to this class and remove the remaining
threads.
Reviewers: ovyalov, clayborg, amccarth, zturner, emaste
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11066
llvm-svn: 242018
jGetLoadedDynamicLibrariesInfos. This packet is similar to
qXfer:libraries:read except that lldb supplies the number of solibs
that should be reported about, and the start address for the list
of them. At the initial process launch we'll read the full list
of solibs linked by the process -- at this point we could be using
qXfer:libraries:read -- but on subsequence solib-loaded notifications,
we'll be fetching a smaller number of solibs, often only one or two.
A typical Mac/iOS GUI app may have a couple hundred different
solibs loaded - doing all of the loads via memory reads takes
a couple of megabytes of traffic between lldb and debugserver.
Having debugserver summarize the load addresses of all the solibs
and sending it in JSON requires a couple of hundred kilobytes
of traffic. It's a significant performance improvement when
communicating over a slower channel.
This patch leaves all of the logic for loading the libraries
in DynamicLoaderMacOSXDYLD -- it only call over ot ProcesGDBRemote
to get the JSON result.
If the jGetLoadedDynamicLibrariesInfos packet is not implemented,
the normal technique of using memory read packets to get all of
the details from the target will be used.
<rdar://problem/21007465>
llvm-svn: 241964
Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.
After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.
This is a resubmit of r241672, after it was reverted due to build failueres on non-linux
platforms.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10996
llvm-svn: 241796
Summary:
This is used on non-unix platforms, where qXfer:libraries-svr4:read
doesn't make sense. Windows uses that for instance.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11036
llvm-svn: 241712
platform-specific symbols that are not implemented on OS X.
The build error that caused this is
Undefined symbols for architecture x86_64:
"lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
"lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
llvm-svn: 241688
Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.
After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.
Reviewers: ovyalov, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10996
llvm-svn: 241672
Make the python target definition file have highest priority so that we can set
the remote stub breakpoint pc offset using it.
Reviewers: clayborg
Subscribers: ted, deepak2427, lldb-commits
Differential revision: http://reviews.llvm.org/D10775
llvm-svn: 241063
- Avoid sending the qfThreadInfo, qsThreadInfo packets if we have a stop reply packet with the threads already (save 2 round trip packets)
- Include the qname, qserial and qkind in the JSON info
- Report the qname, qserial and qkind to the thread so it can cache it to avoid many packets on MacOSX and iOS
- Don't clear all discoverable settings when we exec, just the ones we need to saves 1-5 packets for each exec.
llvm-svn: 240988
There are a couple of bugs in the XML register info handling which this patch fixes:
+ conflicting variable names in lambda, both capture list and parameters contains a variable called 'name'.
+ prev_reg_num, which sets the register number, should be incremented after each register is processed.
+ Windows errors regarding empty strings and the 'xi:' prefix disappearing from 'xi:include' node name.
Reviewers: clayborg
Subscribers: lldb-commits, deepak2427
Differential Revision: http://reviews.llvm.org/D10731
llvm-svn: 240768
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
A "qSymbol::" is sent when shared libraries have been loaded by hooking into the Process::ModulesDidLoad() function from within ProcessGDBRemote. This function was made virtual so that the ProcessGDBRemote version is called, which then first calls the Process::ModulesDidLoad(), and then it queries for any symbol lookups that the remote GDB server might want to do.
This allows debugserver to request the "dispatch_queue_offsets" symbol so that it can read the queue name, queue kind and queue serial number and include this data as part of the stop reply packet. Previously each thread would have to do 3 memory reads in order to read the queue name.
This is part of reducing the number of packets that are sent between LLDB and the remote GDB server.
<rdar://problem/21494354>
llvm-svn: 240466
This patch adds a listener to the AynscThread in ProcessGDBRemote, specifically for dealing with any async notification packets.
From the broadcast our listener receives we can process the notify packet from the event data. A handler function then sets the thread stop info from this packet, and updates lldb by setting the process private state to stopped. Allowing the async thread to go back to sleep and getting the main thread to handle the implications of a state change.
When sending a vCont in nonstop mode we also get a different reply from all-stop mode, an OK response as opposed to a stop reply. So a condition is added to handle this and set the process state without the stop-reply data.
Reviewers: clayborg
Subscribers: lldb-commits, labath, ted, aidan.dodds, deepak2427
Differential Revision: http://reviews.llvm.org/D10544
llvm-svn: 240397
We have been working on reducing the packet count that is sent between LLDB and the debugserver on MacOSX and iOS. Our approach to this was to reduce the packets required when debugging multiple threads. We currently make one qThreadStopInfoXXXX call (where XXXX is the thread ID in hex) per thread except the thread that stopped with a stop reply packet. In order to implement multiple thread infos in a single reply, we need to use structured data, which means JSON. The new jThreadsInfo packet will attempt to retrieve all thread infos in a single packet. The data is very similar to the stop reply packets, but packaged in JSON and uses JSON arrays where applicable. The JSON output looks like:
[
{ "tid":1580681,
"metype":6,
"medata":[2,0],
"reason":"exception",
"qaddr":140735118423168,
"registers": {
"0":"8000000000000000",
"1":"0000000000000000",
"2":"20fabf5fff7f0000",
"3":"e8f8bf5fff7f0000",
"4":"0100000000000000",
"5":"d8f8bf5fff7f0000",
"6":"b0f8bf5fff7f0000",
"7":"20f4bf5fff7f0000",
"8":"8000000000000000",
"9":"61a8db78a61500db",
"10":"3200000000000000",
"11":"4602000000000000",
"12":"0000000000000000",
"13":"0000000000000000",
"14":"0000000000000000",
"15":"0000000000000000",
"16":"960b000001000000",
"17":"0202000000000000",
"18":"2b00000000000000",
"19":"0000000000000000",
"20":"0000000000000000"},
"memory":[
{"address":140734799804592,"bytes":"c8f8bf5fff7f0000c9a59e8cff7f0000"},
{"address":140734799804616,"bytes":"00000000000000000100000000000000"}
]
}
]
It contains an array of dicitionaries with all of the key value pairs that are normally in the stop reply packet. Including the expedited registers. Notice that is also contains expedited memory in the "memory" key. Any values in this memory will get included in a new L1 cache in lldb_private::Process where if a memory read request is made and that memory request fits into one of the L1 memory cache blocks, it will use that memory data. If a memory request fails in the L1 cache, it will fall back to the L2 cache which is the same block sized caching we were using before these changes. This allows a process to expedite memory that you are likely to use and it reduces packet count. On MacOSX with debugserver, we expedite the frame pointer backchain for a thread (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for the previous FP and PC), and follow the backchain. Most backtraces on MacOSX and iOS now don't require us to read any memory!
We will try these packets out and if successful, we should port these to lldb-server in the near future.
<rdar://problem/21494354>
llvm-svn: 240354
For some communication channels, sending large packets can be very
slow. In those cases, it may be faster to compress the contents of
the packet on the target device and decompress it on the debug host
system. For instance, communicating with a device using something
like Bluetooth may be an environment where this tradeoff is a good one.
This patch adds a new field to the response to the "qSupported" packet
(which returns a "qXfer:features:" response) -- SupportedCompressions
and DefaultCompressionMinSize. These tell you what the remote
stub can support.
lldb, if it wants to enable compression and can handle one of those
algorithms, it can send a QEnableCompression packet specifying the
algorithm and optionally the minimum packet size to use compression
on. lldb may have better knowledge about the best tradeoff for
a given communication channel.
I added support to debugserver an lldb to use the zlib APIs
(if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the
libcompression APIs on Mac OS X 10.11 and later
(if -DHAVE_LIBCOMPRESSION=1). libz "zlib-deflate" compression.
libcompression can support deflate, lz4, lzma, and a proprietary
lzfse algorithm. libcompression has been hand-tuned for Apple
hardware so it should be preferred if available.
debugserver currently only adds the SupportedCompressions when
it is being run on an Apple watch (TARGET_OS_WATCH). Comment
that #if out from RNBRemote.cpp if you want to enable it to
see how it works. I haven't tested this on a native system
configuration but surely it will be slower to compress & decompress
the packets in a same-system debug session.
I haven't had a chance to add support for this to
GDBRemoteCommunciationServer.cpp yet.
<rdar://problem/21090180>
llvm-svn: 240066
In order to support asynchronous notifications for non-stop mode this patch adds a packet read thread. This is done by implementing AppendBytesToCache() from the communications class, which continually reads packets into a packet queue. To initialize this thread StartReadThread() must be called by the client, so since llgs and platform tools use the GBDRemoteCommunicatos code they must also call this function as well as ProcessGDBRemote.
When the read thread detects an async notify packet it broadcasts this event, where the matching listener will be added in the next non-stop patch.
Packets are now accessed by calling ReadPacket() which pops a packet from the queue, instead of using WaitForPacketWithTimeoutMicroSecondsNoLock()
Reviewers: vharron, clayborg
Subscribers: lldb-commits, labath, ted, domipheus, deepak2427
Differential Revision: http://reviews.llvm.org/D10085
llvm-svn: 239824
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
Summary:
Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception"
to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the
user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since
LLDB was unable to reinject this signal back into the inferior.
This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the
test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it
uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with
signal=SIGSEGV.
I have also added the ability to set the description of StopInfoUnixSignal using the description
field of the gdb-remote packet. The linux stub uses this to display additional information about
the segfault (invalid address, address access protected, etc.).
Test Plan: All tests pass on linux and osx.
Reviewers: ovyalov, clayborg, emaste
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D10057
llvm-svn: 238549
qEcho:%s
where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received!
This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen:
--> "abc"
<-- <<<error: timeout>>>
Now we want to send "def" and get "DEF" back:
--> "def"
<-- "ABC"
We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands.
The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- "abc"
<-- "qEcho:1"
The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time...
In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
We then disconnect and say we lost connection.
We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- "qEcho:1"
Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug.
<rdar://problem/21082939>
llvm-svn: 238530
In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info.
However in non-stop mode we can receive several stop reply packets in a sequence for different threads. As a result we need to use a container to hold them before they are processed.
This patch also changes the return type of CheckPacket() so we can detect async notification packets.
Reviewers: clayborg
Subscribers: labath, ted, deepak2427, lldb-commits
Differential Revision: http://reviews.llvm.org/D9853
llvm-svn: 238323
This change also get rid of an unused Debugger instance in
GDBRemoteCommunicationServerLLGS and the command interpreter from
lldb-platform what was used only for enabling logging.
Differential revision: http://reviews.llvm.org/D9876
llvm-svn: 238319
We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled.
Converted all locations that used XML over to using the host XML implementation.
Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet.
<rdar://problem/21090173>
llvm-svn: 238224
The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat.
Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit().
Now we aren't leaking file descriptors and the stand alone test suite should run much better.
llvm-svn: 238089
Summary:
The test in TestPlatformCommand which runs "platform process list" has
been timing out for Android when running running dosep.py with
LLDB_TEST_THREADS=8. This patch increases the packet timeout to a large
value of 1min to accommodate the long time required for a response for
the qfProcessInfo packet on Android.
Test Plan: LLDB_TEST_THREADS=8 ./dosep.py on Android.
Reviewers: chaoren
Reviewed By: chaoren
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9866
llvm-svn: 237752
r237411 exposed the following issue: ProcessGDBRemote used the description field in the
stop-reply to set the description of the StopInfo. In the case of watchpoints, the packet
description contains the raw address that got hit, which is not exactly the information we want
to display to the user as the stop info. Therefore, I have changed the code to use the packet
description only if the StopInfo does not already have a description. This makes the behavior
equivalent to the pre-r237411 behavior as then the SetDecription call got ignored for
watchpoints.
llvm-svn: 237436
There were two versions of DoAttachToprocessWithId. One that takes
a pid_t, and the other which takes a pid_t and a ProcessAttachInfo.
There were no callers of the former version, and all of the
implementations of this version were simply forwarding calls to
one version or the other.
llvm-svn: 237281
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
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
Summary:
GetCurrentDirectory() returns the number of characters copied; 0 is a failure, not a success.
Add implementation for chdir().
Reviewers: zturner
Reviewed By: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9300
llvm-svn: 237162
Summary:
New dotest options that allow arbitrary log channels and
categories to be enabled. Also enables logging for locally run
debug servers.
Log messages are separated into separate files per test case.
(this makes it possible to log in dosep runs)
These new log files are stored side-by-side with trace files in the
session directory.
These files are deleted by default if the test run is successful.
If --log-success is specified, even successful logs are retained.
--log-success is useful for creating reference log files.
Test Plan:
add '--channel "lldb all" --channel "gdb-remote packets" --log-success'
to your dotest options
Tested on OSX and Linux
Differential Revision: http://reviews.llvm.org/D9594
llvm-svn: 236956
Summary:
NativeProcessProtocol uses ReadMemory internally for setting/checking
breakpoints but also for generic memory reads (Handle_m), this change adds a
ReadMemoryWithoutTrap for that purpose. Also fixes a bunch of misuses of addr_t
as size/length.
Test Plan: `disassemble` no longer shows the trap code.
Reviewers: jingham, vharron, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9330
llvm-svn: 236132
Summary:
Currently, launching lldb-gdbserver from platform on Android requires root for
mkfifo() and an explicit TMPDIR variable. This should remove both requirements.
Test Plan: Successfully launched lldb-gdbserver on a non-rooted Android device.
Reviewers: tberghammer, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9307
llvm-svn: 235940
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
Also add "#if defined( LIBXML2_DEFINED )" around code that already used libxml2 in SymbolVendorMacOSX.cpp.
Cleaned up some warnings in ProcessGDBRemote.cpp.
llvm-svn: 235144
Typically, LLGS only sends stdout/stderr notifications when the inferior
process is running.
Because LLGS reads stdout from the process in a separate thread, sometimes
these stdout notifications can be received after the server has sent a thread
stop message. The host isn't expecting stdout to be generated by the target
after a stop message and these messages interfere with the host's request/
response paradigm.
Differential Revision: http://reviews.llvm.org/D9024
llvm-svn: 234995
Previously the remote module sepcification was fetched only from the
remote platform. With this CL if we have a remote process then we ask it
if it have any information from a given module. It is required because
on android the dynamic linker only reports the name of the SO file and
the platform can't always find it without a full path (the process can
do it based on /proc/<pid>/maps).
Differential revision: http://reviews.llvm.org/D8547
llvm-svn: 233061
Some application on Linux an all application on android close stdout and
stderr during the libc exit stage. Previously the master file descriptor
of the pseudo terminal used to communicate with the inferior was closed
on an EOF causing a race condition and a possible SIGHUP on process
exit. After this change the master file descriptor will be closed by the
destructor of the GDBRemoteCommunicationServerLLGS class.
Differential revision: http://reviews.llvm.org/D8436
llvm-svn: 232724
This moves the conversion of the open options to the target platform. On mac fcntl.h has different values for O_CREAT and O_TRUNC than on linux so by transmitting the standardized lldb open options we can correctly convert them on the target platform.
Test Plan:
On linux:
lldb-server p --listen *:1234
On mac:
lldb
platform select remote-linux
platform connect connect://ip-of-linux-box:1234
target create ~/path/to/linux/binary
b main
process launch
Binary is successfully pushed to linux remote, process successfully launches and break in the main method.
Differential Revision: http://reviews.llvm.org/D8395
llvm-svn: 232634
This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
The file path is currently required on android because the executables
only contain the name of the system libraries without their path. This
CL add an extra field to the qModuleInfo packet to return the full path
of a modul and add logic to locate a shared module on android.
Differential revision: http://reviews.llvm.org/D8221
llvm-svn: 232156
Previously it was fetched only if the architecture isn't valid, but the
architecture can be valid without containing all information about the
current target (e.g. missing os).
Differential revision: http://reviews.llvm.org/D8057
llvm-svn: 232153
This was previously initialized by ProcessGDBRemote::Initialize but lldb-server does not contain ProcessGDBRemote anymore so this needs to be initialized directly.
Differential Revision: http://reviews.llvm.org/D8186
llvm-svn: 231966
Summary:
ProcessGDBRemote::AsyncThread nuked its own thread handle upon exiting. This prevented the main
thread from joining it correctly in StopAsyncThread. I address this by moving the Reset() call to
StopAsyncThread, after the join.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8218
llvm-svn: 231915
Setting it from the Target architecture cause problems when the target
archiutecture is filled just by examining the executable because in that
case the OS isn't set.
Differential revision: http://reviews.llvm.org/D8035
llvm-svn: 231234
Summary:
Before this fix the FileSpec::GetPath() returned string which might be without '\0' at the end.
It could have happened if the size of buffer for path was less than actual path.
Test case:
```
FileSpec test("/path/to/file", false);
char buf[]="!!!!!!";
test.GetPath(buf, 3);
```
Before fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/pa!!!"
```
After fix:
```
233 FileSpec test("/path/to/file", false);
234 char buf[]="!!!!!!";
235 test.GetPath(buf, 3);
236
-> 237 if (core_file)
238 {
239 if (!core_file.Exists())
240 {
(lldb) print buf
(char [7]) $0 = "/p"
```
Reviewers: zturner, abidh, clayborg
Reviewed By: abidh, clayborg
Subscribers: tberghammer, vharron, lldb-commits, clayborg, zturner, abidh
Differential Revision: http://reviews.llvm.org/D7553
llvm-svn: 230787
This new class makes it easier to change the timeout of a
GDBRemoteCommunication instance for a short time and then restore it to
its original value.
Differential revision: http://reviews.llvm.org/D7826
llvm-svn: 230319
With the previous implementation the protocol used by the client and the
server for the response was different and worked only by an accident.
With this change the communication is fixed and the return code from
mkdir and chmod correctly captured by lldb. The change also add
documentation for the qPlatform__[mkdir,chmod] packages.
Differential revision: http://reviews.llvm.org/D7786
llvm-svn: 230213
This commit merges lldb-platform and lldb-gdbserver into a single binary
of the same size as each of the previous individual binaries. Execution
mode is controlled by the first argument being either platform or
gdbserver.
Patch from: flackr <flackr@google.com>
Differential revision: http://reviews.llvm.org/D7545
llvm-svn: 229683
Oleksiy Vyalov