This can include objects that have complex state and need to be torn down intelligently (e.g. our SB* objects)
This will fail if the Python interpreter does not hold a valid thread state. So, acquire one, delete the session dictionary, and then let go of it on destruction
This fixes rdar://20960843
llvm-svn: 242745
We previously passed in a 8192 byte buffer but this wasn't large enough. We now calculate the size we need and then add 128 to it and get the environment. If we pass exactly the number of bytes it says is needs, the sysctl() returns junk. Adding 1 seemed to do the trick, but to err on the side of caution, I added a few bytes more.
<rdar://problem/21883842>
llvm-svn: 242729
for a CXXRecordDecl gets pointed at that record. This can happen when a type is
imported out of and then into the target's AST context without being laid out.
Also added a testcase that covers this scenario.
<rdar://problem/21844453>
llvm-svn: 242687
Make sure we dont treat EINTR as a fatal error. I was getting this when trying to profile the
debugger. I'm not sure why this wasn't surfacing before, it could be that the profiler is using
some signals internally.
llvm-svn: 242681
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
Don't chane the CFI information when a conditional instruction
is emulated (eg.: popeq {r0, pc}) because the CFI for the next
instruction should be the same as the CFI for the current instruction.
Differential revision: http://reviews.llvm.org/D11258
llvm-svn: 242519
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
Upon connection termination the waitable handle of an IOObject gets reset to an invalid handle.
This caused a problem since we used the object->GetWaitableHandle as a key to the set of
registered events. The fix is to use something more immutable as a key: we make a copy of the
original waitable handle, instead of holding onto the IOObject.
llvm-svn: 242515
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
SUMMARY:
The patch detects MIPS application specific extensions (ASE) like micromips by reading
ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE
information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags
or SHT_MIPS_ABIFLAGS section.
Reviewers: clayborg
Subscribers: mohit.bhakkad, sagar, lldb-commits
Differential Revision: http://reviews.llvm.org/D11133
llvm-svn: 242381
Summary:
Other changes around the main change include:
1. Add a method Cast to ValueObjectConstResult, ValueObjectConstResultImpl
and ValueObjectConstResultChild.
2. Add an argument |live_address| of type lldb::addr_t to the constructor
of ValueObjectConstResultChild. This is passed on to the backing
ValueObjectConstResultImpl object constructor so that the address of the
child value can be calculated properly.
Reviewers: granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11203
llvm-svn: 242374
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
This one I accidentally missed last time because I confused it with
the lldbUtility library. After this, all makefile libraries should
have the same names as their CMake counterparts.
llvm-svn: 242344
Summary:
The accept4 syscall is missing on older ARM Android kernels, and the accept()
call is implemented with the accept4 syscall, so we'll need to call the accept
syscall directly.
Reviewers: vharron, tberghammer, labath
Subscribers: ovyalov, chaoren, labath, tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10887
llvm-svn: 242319
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: This aligns the library names used by the Makefile build to be the same as those create by the CMake build to make switching between the two easier. The only major difficulty was lldbHost which was one library in the CMake system and several in the Makefile system. Most of the other changes are trivial renames.
Reviewers: labath
Subscribers: emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11154
llvm-svn: 242196
For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support.
Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls.
In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation.
To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter.
The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values.
Reviewers: jingham, spyffe
Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427
Differential Revision: http://reviews.llvm.org/D9404
llvm-svn: 242137
Existing commands supplying this type of help content have been reworked to take advantage of the changes. In addition to formatting changes, content was changes for accuracy and clarity purposes.
<rdar://problem/21269977>
llvm-svn: 242122
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:
r241964 has added a dependency on uuid.h, which (on linux at least) necessitates instalation of a
new package. Since the only thing we need from that file is uuid_t (and this is already defined
in UuidCompatibility.h), we can avoid this dependency by making this include __APPLE__ specific.
If in future, we need more from this library, we can revisit this decision.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11135
llvm-svn: 242022
The size of a long double was hardcoded in DataExtractor for x86 and
x86_64 architectures. This CL removes the hard coded values and use the
actual size based on the floating point semantics specified.
Differential revision: http://reviews.llvm.org/D8417
llvm-svn: 242019
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
On Android the oatdata and the oatexec symbols in
system@framework@boot.oat covers the full .text section what causes
issues with displaying unusable symbol name to the user and very slow
unwinding speed because the instruction emulation based unwind plans
try to emulate all instructions in these symbols. Don't add these
symbols to the symbol list as they have no use for the debugger and
they are causing a lot of trouble.
Differential revision: http://reviews.llvm.org/D11065
llvm-svn: 242017
This patch:
- Allows mips32 cores to match with any mips32/mips64 cores.
- Allows mips32r2 cores to match with core only up-to mips32r2/mips64r2.
- Allows mips32r3 cores to match with core only up-to mips32r3/mips64r3.
- Allows mips32r5 cores to match with core only up-to mips32r3/mips64r5.
- Allows mips32r6 core to match with only mips32r6/mips64r6 or mips32/mips64.
Reviewers: emaste, jaydeep, clayborg
Subscribers: mohit.bhakkad, nitesh.jain, bhushan, lldb-commits
Differential Revision: http://reviews.llvm.org/D10921
llvm-svn: 242016
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