|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
bff4673b |
| 11-May-2022 |
Jim Ingham <[email protected]> |
Add a darwin platform setting to specify which exceptions debugserver should not receive as exceptions (some will get converted to BSD signals instead). This is really the only stable way to ensure
Add a darwin platform setting to specify which exceptions debugserver should not receive as exceptions (some will get converted to BSD signals instead). This is really the only stable way to ensure that a Mach exception gets converted to it's equivalent BSD signal. For programs that rely on BSD signal handlers, this has to happen or you can't even get the program to invoke the signal handler when under the debugger.
This builds on a previous solution to this problem which required you start debugserver with the -U flag. This was not very discoverable and required lldb be the one to launch debugserver, which is not always the case.
Differential Revision: https://reviews.llvm.org/D125434
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init |
|
| #
b2e25572 |
| 20-Jul-2021 |
Jason Molenda <[email protected]> |
Remove the DarwinLog functionality from debguserver
Remove the DarwinLog and qStructuredDataPlugins support from debugserver. The DarwinLog plugin was never debugged fully and made reliable, and th
Remove the DarwinLog functionality from debguserver
Remove the DarwinLog and qStructuredDataPlugins support from debugserver. The DarwinLog plugin was never debugged fully and made reliable, and the underlying private APIs it uses have migrated since 2016 so none of them exist any longer.
Differential Revision: https://reviews.llvm.org/D106324 rdar://75073283
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
cdc514e4 |
| 17-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pa
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
c1874097 |
| 15-May-2019 |
Jonas Devlieghere <[email protected]> |
Mark private unimplemented functions as deleted
Applies modernize-use-equals-delete to the LLDB code base and removes the now redundant comments.
llvm-svn: 360751
|
| #
efe8e7e3 |
| 14-May-2019 |
Fangrui Song <[email protected]> |
typedef enum -> enum
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D61883
llvm-svn: 360654
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <[email protected]> |
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging t
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3 |
|
| #
75930019 |
| 19-Aug-2016 |
Todd Fiala <[email protected]> |
Add StructuredData plugin type; showcase with new DarwinLog feature
Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugi
Add StructuredData plugin type; showcase with new DarwinLog feature
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
show more ...
|
| #
a07e4a83 |
| 19-Aug-2016 |
Todd Fiala <[email protected]> |
Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8.
llvm-svn: 279200
|
| #
aef7de84 |
| 19-Aug-2016 |
Todd Fiala <[email protected]> |
Add StructuredData plugin type; showcase with new DarwinLog feature
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: c
Add StructuredData plugin type; showcase with new DarwinLog feature
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham llvm-svn: 279198
show more ...
|
|
Revision tags: llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
a2992311 |
| 07-Jul-2016 |
Jason Molenda <[email protected]> |
Add support to debugserver for some new ways to interact with dyld to find the solibs loaded in a process. Support two new ways of sending the jGetLoadedDynamicLibrariesInfos packet to debugserver a
Add support to debugserver for some new ways to interact with dyld to find the solibs loaded in a process. Support two new ways of sending the jGetLoadedDynamicLibrariesInfos packet to debugserver and add a new jGetSharedCacheInfo packet. Update the documentation for these packets as well. The changes to lldb to use these will be a separate commit.
<rdar://problem/25251243>
llvm-svn: 274718
show more ...
|
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1 |
|
| #
77f89352 |
| 12-Jan-2016 |
Jason Molenda <[email protected]> |
Changes to lldb and debugserver to reduce extraneous memory reads at each public stop to improve performance a bit. Most of the information lldb needed was already in the jThreadsInfo response; com
Changes to lldb and debugserver to reduce extraneous memory reads 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
show more ...
|
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1, llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2 |
|
| #
a026de05 |
| 22-Jul-2015 |
Bruce Mitchener <[email protected]> |
Fix warnings.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11404
llvm-svn: 242913
|
| #
2e309076 |
| 17-Jul-2015 |
Greg Clayton <[email protected]> |
More packet performance improvements.
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
More packet performance improvements.
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
show more ...
|
|
Revision tags: llvmorg-3.7.0-rc1 |
|
| #
a5801ade |
| 15-Jul-2015 |
Greg Clayton <[email protected]> |
Added the ability to get JSON thread stop info with thread ID and stop info only in the normal stop reply packets using the new "jthreads" key value pair.
This allows stepping operations that don't
Added the ability to get JSON thread stop info with thread ID and stop info only in the normal stop reply packets using the new "jthreads" key value pair.
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
show more ...
|
| #
20ee21bd |
| 10-Jul-2015 |
Jason Molenda <[email protected]> |
Add a another packet to the gdb-remote protocol, jGetLoadedDynamicLibrariesInfos. This packet is similar to qXfer:libraries:read except that lldb supplies the number of solibs that should be reporte
Add a another packet to the gdb-remote protocol, 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
show more ...
|
| #
358cf1ea |
| 25-Jun-2015 |
Greg Clayton <[email protected]> |
Resubmitting 240466 after fixing the linux test suite failures.
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were ac
Resubmitting 240466 after fixing the linux test suite failures.
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
show more ...
|
|
Revision tags: llvmorg-3.6.2 |
|
| #
0b90be1c |
| 23-Jun-2015 |
Greg Clayton <[email protected]> |
Implement the "qSymbol" packet in order to be able to read queue information in debugserver and return the info in the stop reply packets.
A "qSymbol::" is sent when shared libraries have been loade
Implement the "qSymbol" packet in order to be able to read queue information 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
show more ...
|
|
Revision tags: llvmorg-3.6.2-rc1 |
|
| #
7a306080 |
| 23-Jun-2015 |
Chaoren Lin <[email protected]> |
Revert "Reduced packet counts to the remote GDB server where possible."
This reverts commit 0cc0745ea9c68d7fdcadc9904cee3f13c96dae60.
Due to breakage on Linux build bot:
http://lab.llvm.org:8011/b
Revert "Reduced packet counts to the remote GDB server where possible."
This reverts commit 0cc0745ea9c68d7fdcadc9904cee3f13c96dae60.
Due to breakage on Linux build bot:
http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/3436
llvm-svn: 240371
show more ...
|
| #
ffb2d44a |
| 22-Jun-2015 |
Greg Clayton <[email protected]> |
Reduced packet counts to the remote GDB server where possible.
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
Reduced packet counts to the remote GDB server where possible.
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
show more ...
|
| #
91ffe0a5 |
| 18-Jun-2015 |
Jason Molenda <[email protected]> |
Add a new wart, I mean feature, on to gdb-remote protocol: compression. For some communication channels, sending large packets can be very slow. In those cases, it may be faster to compress the con
Add a new wart, I mean feature, on to gdb-remote protocol: compression. 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
show more ...
|
| #
b30c50c8 |
| 29-May-2015 |
Greg Clayton <[email protected]> |
Add a new "qEcho" packet with the following format:
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 receive
Add a new "qEcho" packet with the following format:
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
show more ...
|
| #
d04f0eda |
| 26-May-2015 |
Greg Clayton <[email protected]> |
Added XML to the host layer.
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
Added XML to the host layer.
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
show more ...
|
|
Revision tags: llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1, llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1 |
|
| #
6a7f3338 |
| 27-Jun-2014 |
Bruce Mitchener <[email protected]> |
Fix a few typos.
llvm-svn: 211851
|
| #
106d0286 |
| 25-Jun-2014 |
Jim Ingham <[email protected]> |
Added an option to turn OFF the "detach on error" behavior that was added to debugserver when launching processes.
<rdar://problem/16216199>
llvm-svn: 211658
|