summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
Commit message (Collapse)AuthorAgeFilesLines
* Use llvm::VersionTuple instead of manual version marshallingPavel Labath2018-06-181-2/+1
| | | | | | | | | | | | | | | | | | Summary: This has multiple advantages: - we need only one function argument/instance variable instead of three - no need to default initialize variables - no custom parsing code - VersionTuple has comparison operators, which makes version comparisons much simpler Reviewers: zturner, friss, clayborg, jingham Subscribers: emaste, lldb-commits Differential Revision: https://reviews.llvm.org/D47889 llvm-svn: 334950
* Re-land: [lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-03-201-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | regions The difference between this and the previous patch is that now we use ELF physical addresses only for loading objects into the target (and the rest of the module load address logic still uses virtual addresses). Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net>. llvm-svn: 327970
* Revert "[lldb] Use vFlash commands when writing to target's flash memory ↵Pavel Labath2018-02-281-13/+0
| | | | | | | | | | | | regions" This reverts commit r326261 as it introduces inconsistencies in the handling of load addresses for ObjectFileELF -- some parts of the class use physical addresses, and some use virtual. This has manifested itself as us not being able to set the load address of the vdso "module" on android. llvm-svn: 326367
* [lldb] Use vFlash commands when writing to target's flash memory regionsPavel Labath2018-02-271-0/+13
| | | | | | | | | | | | | | | | | | | | | | Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 326261
* Move ArchSpec to the Utility modulePavel Labath2017-11-131-3/+1
| | | | | | | | | | | | | The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
* Remove ProcessGdbRemote::m_flagsPavel Labath2017-11-031-5/+0
| | | | | | The member is completely unused. Discussed on lldb-dev. llvm-svn: 317377
* Move StructuredData from Core to UtilityPavel Labath2017-06-271-1/+1
| | | | | | | | | | | | | | | | Summary: It had a dependency on StringConvert and file reading code, which is not in Utility. I've replaced that code by equivalent llvm operations. I've added a unit test to demonstrate that parsing a file still works. Reviewers: zturner, jingham Subscribers: kubamracek, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D34625 llvm-svn: 306394
* Implementation of remote packets for Trace data.Ravitheja Addepally2017-05-261-0/+16
| | | | | | | | | | | | | | | | | | 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
* Rename Error -> Status.Zachary Turner2017-05-121-39/+39
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move StringList from Core -> Utility.Zachary Turner2017-03-211-1/+1
| | | | llvm-svn: 298412
* Make LLDB skip server-client roundtrip for signals that don't require any ↵Eugene Zemtsov2017-03-071-0/+3
| | | | | | | | | | | | | | actions If QPassSignals packaet is supported by lldb-server, lldb-client will utilize it and ask the server to ignore signals that don't require stops or notifications. Such signals will be immediately re-injected into inferior to continue normal execution. Differential Revision: https://reviews.llvm.org/D30520 llvm-svn: 297231
* Move classes from Core -> Utility.Zachary Turner2017-02-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Prevent client from querying each thread's PC at each stop.Pavel Labath2017-01-201-0/+1
| | | | | | | | | | | | | | | | | | Summary: The server was no longer sending the thread PCs the way the client expected them. I changed the server to send them back as a threadstop info field, similar to the Apple version of the server. I also changed the client to look for them there, before querying the server. I added a test to ensure the server doesn't stop sending them. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D28880 Author: Jason Majors llvm-svn: 292611
* Convert Platform, Process, and Connection functions to StringRef.Zachary Turner2016-11-171-2/+2
| | | | | | All tests pass on Linux and Windows. llvm-svn: 287259
* async structured data packet handling improvementsTodd Fiala2016-09-101-2/+1
| | | | | | | | | | | | | | | | | | | | | | | This change does the following: * Changes the signature for the continuation delegate method that handles async structured data from accepting an already-parsed structured data element to taking just the packet contents. * Moves the conversion of the JSON-async: packet contents from GDBRemoteClientBase to the continuation delegate method. * Adds a new unit test for verifying that the $JSON-asyc: packets get decoded and that the decoded packets get forwarded on to the delegate for further processing. Thanks to Pavel for making that whole section of code easily unit testable! * Tightens up the packet verification on reception of a $JSON-async: packet contents. The code prior to this change is susceptible to a segfault if a packet is carefully crafted that starts with $J but has a total length shorter than the length of "$JSON-async:". Reviewers: labath, clayborg, zturner Differential Revision: https://reviews.llvm.org/D23884 llvm-svn: 281121
* gdb-remote: Add jModulesInfo packetPavel Labath2016-09-081-0/+31
| | | | | | | | | | | | | | | | | | | | | 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
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-438/+336
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-0/+7
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-191-7/+0
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-191-0/+7
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* Reapply "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"Pavel Labath2016-08-091-1/+17
| | | | | | | | | | | | Resumbitting the commit after fixing the following problems: - broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F) - the new code did not correctly handle the case where we went to interrupt the process, but it stopped due to a different reason - the interrupt request would remain queued and would interfere with the following "continue". I also added a unit test for this case. This reapplies r277156 and r277139. llvm-svn: 278118
* Revert "Rewrite gdb-remote's SendContinuePacketAndWaitForResponse"Pavel Labath2016-07-291-17/+1
| | | | | | | | This reverts commit r277139, because: - broken unittest on windows (likely typo on my part) - seems to break TestCallThatRestart (needs investigation) llvm-svn: 277154
* Rewrite gdb-remote's SendContinuePacketAndWaitForResponsePavel Labath2016-07-291-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SendContinuePacketAndWaitForResponse was huge function with very complex interactions with several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any changes to how packet sending functions and threads interact was very difficult and error-prone. This change does not add any functionality yet, it merely paves the way for future changes. In a follow-up, I plan to add the ability to have multiple query packets in flight (i.e., request,request,response,response instead of the usual request,response sequences) and use that to speed up qModuleInfo packet processing. Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread, and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and blocks any other async threads from accessing the connection. Other threads create an instance of the Lock object when they want to access the connection. This object, while in scope prevents the continue from being send. Optionally, it can also interrupt the process to gain access to the connection for async processing. Most of the syncrhonization logic is encapsulated within these two classes. Some of it still had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much more manageable than before -- partly because of most of the work is done in the ContinueLock class, and partly because I have factored out a lot of the packet processing code separate functions (this also makes the functionality more easily testable). Most importantly, there is none of syncrhonization code in the async thread users -- as far as they are concerned, they just need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a very thin wrapper around the NoLock version of the function, whereas previously it had over 100 lines of synchronization code). This will make my follow up changes there easy. I have written a number of unit tests for the new code and I have ran the test suite on linux and osx with no regressions. Subscribers: tberghammer Differential Revision: https://reviews.llvm.org/D22629 llvm-svn: 277139
* Add support to get the shared cache information from the newJason Molenda2016-07-221-0/+3
| | | | | | | | | | | | | debugserver jGetSharedCacheInfo packet instead of reading the dyld internal data structures directly. This code is (currently) only used for ios native lldb's - I should really move this ObjectFileMachO::GetProcessSharedCacheUUID method somewhere else, it makes less and less sense being in the file reader. <rdar://problem/25251243> llvm-svn: 276369
* Add a new DynamicLoader plugin that uses SPI that are in developmentJason Molenda2016-07-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | for the fall (northern hemisphere) 2016 Darwin platforms to learn about loaded images, instead of reading dyld internal data structures. These new SPI don't exist on older releases, and new packets are needed from debugserver to use them (those changes are already committed). I had to change the minimum deployment target for debugserver in the xcode project file to macOS 10.10 so that debugserver will use the [[NSProcessInfo processInfo] operatingSystemVersion] call in MachProcess::GetOSVersionNumbers to get the operarting system version # -- this API is only available in macOS 10.10 and newer ("OS X Yosemite", released Oct 2014). If we have many people building llvm.org lldb on older systems still, we can back off on this for the llvm.org sources. There should be no change in behavior with this commit, either to older darwin systems or newer darwin systems. For now the new DynamicLoader plugin is never activated - I'm forcing the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI. I'll remove that unconditional use of the old plugin soon, so the newer plugin is used on the newest Darwin platforms. <rdar://problem/25251243> llvm-svn: 276254
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-2/+3
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix a race in ProcessGDBRemote::MonitorDebugServerProcessPavel Labath2016-05-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: MonitorDebugServerProcess went to a lot of effort to make sure its asynchronous invocation does not cause any mischief, but it was still not race-free. Specifically, in a quick stop-restart sequence (like the one in TestAddressBreakpoints) the copying of the process shared pointer via target_sp->GetProcessSP() was racing with the resetting of the pointer in DeleteCurrentProcess, as they were both accessing the same shared_ptr object. To avoid this, I simply pass in a weak_ptr to the process when the callback is created. Locking this pointer is race-free as they are two separate object even though they point to the same process instance. This also removes the need for the complicated tap-dance around retrieving the process pointer. Reviewers: clayborg Subscribers: tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D20107 llvm-svn: 269281
* Generalize child process monitoring functionsPavel Labath2016-05-111-5/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the C-style "void *" baton of the child process monitoring functions with a more C++-like API taking a std::function. The motivation for this was that it was very difficult to handle the ownership of the object passed into the callback function -- each caller ended up implementing his own way of doing it, some doing it better than others. With the new API, one can just pass a smart pointer into the callback and all of the lifetime management will be handled automatically. This has enabled me to simplify the rather complicated handshake in Host::RunShellCommand. I have left handling of MonitorDebugServerProcess (my original motivation for this change) to a separate commit to reduce the scope of this change. Reviewers: clayborg, zturner, emaste, krytarowski Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20106 llvm-svn: 269205
* Revert "Reduce code duplication in ProcessGDBRemote"Pavel Labath2016-04-071-3/+0
| | | | | | | 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
* Reduce code duplication in ProcessGDBRemotePavel Labath2016-04-061-0/+3
| | | | | | | | | | | | | | | | 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
* Allow gdbremote process to read modules from memoryStephane Sezer2016-04-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-071-3/+3
| | | | | | | | | | | | | | 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
* Make sure code that is in the middle of figuring out the correct architectureJim Ingham2016-02-181-1/+1
| | | | | | | | | 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
* Increase use of svr4 packets to improve performance on POSIX remotesStephane Sezer2016-01-121-3/+5
| | | | | | | | | | | | | | | | | | | | 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
* Changes to lldb and debugserver to reduce extraneous memory readsJason Molenda2016-01-121-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* The lldb side changes to go along with r255711 where a newJason Molenda2015-12-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | "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
* Prevent ProcessGDBRemote from launching local debug server in case of remote ↵Oleksiy Vyalov2015-11-231-0/+3
| | | | | | | | debug server connection failure. http://reviews.llvm.org/D14895 llvm-svn: 253906
* Let the process help figure out the Host OS if nobody elseJim Ingham2015-11-051-0/+5
| | | | | | can figure it out. llvm-svn: 252224
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-241-58/+53
| | | | | | source/Plugins; other minor fixes. llvm-svn: 251167
* Fix deadlock while attaching to inferiorsPavel Labath2015-09-031-0/+1
| | | | | | | | | | | | | | | | | | | | 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
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-011-3/+3
| | | | llvm-svn: 246578
* Make ProcessGDBRemote get a //copy// of platform Unix signals.Chaoren Lin2015-09-011-0/+3
| | | | | | | | | | | | Summary: Update to http://reviews.llvm.org/rL243618. Reviewers: jaydeep, clayborg Subscribers: labath, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D12420 llvm-svn: 246557
* Understand absolute base addresses in ProcessGDBRemote::GetLoadedModuleList.Stephane Sezer2015-08-201-1/+1
| | | | | | | | | | | | | | | | 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
* Fix typos.Bruce Mitchener2015-07-221-1/+1
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* More packet performance improvements. Greg Clayton2015-07-171-2/+9
| | | | | | | | 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
* Add a another packet to the gdb-remote protocol,Jason Molenda2015-07-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix cmake build after recent JSON changesPavel Labath2015-07-071-1/+1
| | | | | | | I have moved StringExtractor.h into the include/ folder so that it can be properly included by everyone. llvm-svn: 241572
* More packet reduction when debugging with GDB server.Greg Clayton2015-06-291-1/+8
| | | | | | | | | - 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
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-251-0/+19
| | | | | | | | | | | | | | | 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
* Implement the "qSymbol" packet in order to be able to read queue information ↵Greg Clayton2015-06-231-0/+3
| | | | | | | | | | | | | | in debugserver and return the info in the stop reply packets. 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
OpenPOWER on IntegriCloud