Revision tags: 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, working, 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, 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 |
|
#
ac666d17 |
| 24-Jan-2022 |
Michał Górny <mgorny@moritz.systems> |
[lldb] [gdb-remote] Support getting siginfo via API
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server.
Differential Revision: https://reviews.llv
[lldb] [gdb-remote] Support getting siginfo via API
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
show more ...
|
#
59a3f65f |
| 28-Jan-2022 |
Michał Górny <mgorny@moritz.systems> |
Revert "[lldb] [gdb-remote] Support getting siginfo via API"
This reverts commit 1a8f60f5f5b8638a3e8e7fb31ba7ae9e17a7ff2d. The API requires further work.
|
#
1a8f60f5 |
| 24-Jan-2022 |
Michał Górny <mgorny@moritz.systems> |
[lldb] [gdb-remote] Support getting siginfo via API
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server.
Differential Revision: https://reviews.llv
[lldb] [gdb-remote] Support getting siginfo via API
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server.
Differential Revision: https://reviews.llvm.org/D118055
show more ...
|
Revision tags: 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, 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 |
|
#
4fd77668 |
| 15-Jan-2021 |
Muhammad Omair Javaid <omair.javaid@linaro.org> |
[LLDB] Add per-thread register infos shared pointer in gdb-remote
In gdb-remote process we have register infos defind as a refernce object of GDBRemoteDynamicRegisterInfo class. In past register inf
[LLDB] Add per-thread register infos shared pointer in gdb-remote
In gdb-remote process we have register infos defind as a refernce object of GDBRemoteDynamicRegisterInfo class. In past register infos have remained constant througout the life time of a process.
This has changed after AArch64 SVE support where register infos will have per-thread configuration. SVE registers will have per-thread size and can be updated while running. This patch aims to build up for that support by changing GDBRemoteDynamicRegisterInfo reference to a shared pointer deinfed per-thread.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D82857
show more ...
|
Revision tags: 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 <jonas@devlieghere.com> |
[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 |
|
#
bd689b9c |
| 02-May-2019 |
Saleem Abdulrasool <compnerd@compnerd.org> |
gdb-remote: reduce some inclusion of Target/Process.h
Reduce the inclusion of Target/Process.h to help isolate why Process is being preserved during the build of `lldb-server`.
llvm-svn: 359811
|
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 <chandlerc@gmail.com> |
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 |
|
#
ceff6644 |
| 11-Nov-2018 |
Jonas Devlieghere <jonas@devlieghere.com> |
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdate
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
llvm-svn: 346626
show more ...
|
Revision tags: 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 |
|
#
f2a8bccf |
| 27-Jun-2017 |
Pavel Labath <labath@google.com> |
Move StructuredData from Core to Utility
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 ad
Move StructuredData from Core to Utility
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
show more ...
|
Revision tags: 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 <katherine.stone@apple.com> |
*** 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 |
|
#
b42b48e0 |
| 19-Aug-2016 |
Pavel Labath <labath@google.com> |
Remove the last manually constructed packet from gdb-remote register context + small refactor
Summary: The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting h
Remove the last manually constructed packet from gdb-remote register context + small refactor
Summary: The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting hex-encoded data (as that was what the first implementation I replaced was using, but here we had binary data to begin with. I thought the read/write register functions would be more useful if they handled the hex-encoding themselves (all the other client functions provide the responses in a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that can be constructed from pretty much anything.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23659
llvm-svn: 279232
show more ...
|
Revision tags: llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1, 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 <jmolenda@apple.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; 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 ...
|
#
545304d3 |
| 18-Dec-2015 |
Jason Molenda <jmolenda@apple.com> |
The lldb side changes to go along with r255711 where a new "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 th
The lldb side changes to go along with r255711 where a new "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
show more ...
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
#
edb35d95 |
| 24-Oct-2015 |
Eugene Zelenko <eugene.zelenko@gmail.com> |
Fix Clang-tidy modernize-use-override warnings in some files in source/Plugins; other minor fixes.
llvm-svn: 251167
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, studio-1.4, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2 |
|
#
0b90be1c |
| 23-Jun-2015 |
Greg Clayton <gclayton@apple.com> |
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, llvmorg-3.6.1, llvmorg-3.6.1-rc1 |
|
#
db264a6d |
| 31-Mar-2015 |
Tamas Berghammer <tberghammer@google.com> |
Move several plugin to its own namespace
Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remot
Move several plugin to its own namespace
Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remote/*
Differential revision: http://reviews.llvm.org/D8654
llvm-svn: 233679
show more ...
|
#
30b8cd33 |
| 23-Mar-2015 |
Tamas Berghammer <tberghammer@google.com> |
Remove virtual and add override to all virtual functions in Process/gdb-remote.
llvm-svn: 232952
|
Revision tags: 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 |
|
#
705b1809 |
| 13-Jun-2014 |
Jason Molenda <jmolenda@apple.com> |
Initial merge of some of the iOS 8 / Mac OS X Yosemite specific lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done.
This adds a new SBExpressionOptions:
Initial merge of some of the iOS 8 / Mac OS X Yosemite specific lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use.
I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result.
llvm-svn: 210874
show more ...
|
Revision tags: llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2 |
|
#
2dd5deb1 |
| 25-Apr-2014 |
Jason Molenda <jmolenda@apple.com> |
Missed this file with the r207160 commit.
llvm-svn: 207161
|
Revision tags: llvmorg-3.4.1-rc1 |
|
#
aac16e0f |
| 13-Mar-2014 |
Jason Molenda <jmolenda@apple.com> |
Add a SBQueue::GetKind() method to retrieve the type of libdispatch queue (serial or concurrent). <rdar://problem/7964505>
llvm-svn: 203748
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1 |
|
#
b57e4a1b |
| 04-Nov-2013 |
Jason Molenda <jmolenda@apple.com> |
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
show more ...
|
#
f23bf743 |
| 02-Nov-2013 |
Jason Molenda <jmolenda@apple.com> |
Add a new base class, Frame. It is a pure virtual function which defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends ar
Add a new base class, Frame. It is a pure virtual function which defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to StackFrames.
This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point.
<rdar://problem/15314068>
llvm-svn: 193907
show more ...
|
#
3dc4f44e |
| 18-Oct-2013 |
Jason Molenda <jmolenda@apple.com> |
Move the code which translates a dispatch_qaddr into a queue name out of ProcessGDBRemote and in to the Platform plugin, specifically PlatformDarwin.
Also add a Platform method to translate a dispat
Move the code which translates a dispatch_qaddr into a queue name out of ProcessGDBRemote and in to the Platform plugin, specifically PlatformDarwin.
Also add a Platform method to translate a dispatch_quaddr to a QueueID, and a Thread::GetQueueID().
I'll add an SBThread::GetQueueID() next.
llvm-svn: 192949
show more ...
|
Revision tags: llvmorg-3.3.1-rc1, llvmorg-3.3.0, llvmorg-3.3.0-rc3, llvmorg-3.3.0-rc2 |
|
#
6e0ff1a3 |
| 09-May-2013 |
Greg Clayton <gclayton@apple.com> |
Changed the formerly pure virtual function:
namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; }
To not be virtual. The lldb
Changed the formerly pure virtual function:
namespace lldb_private { class Thread { virtual lldb::StopInfoSP GetPrivateStopReason() = 0; }; }
To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function:
namespace lldb_private { class Thread { virtual bool CalculateStopInfo() = 0; } }
This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings.
Also renamed:
lldb::StopInfoSP lldb_private::Thread::GetPrivateStopReason();
To:
lldb::StopInfoSP lldb_private::Thread::GetPrivateStopInfo();
Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads).
llvm-svn: 181501
show more ...
|
Revision tags: llvmorg-3.3.0-rc1 |
|
#
160c9d81 |
| 01-May-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13700260> <rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" ke
<rdar://problem/13700260> <rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced: - lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread. - Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification. - Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them - Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
show more ...
|