aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/Process/gdb-remote/ThreadGDBRemote.cpp
AgeCommit message (Collapse)AuthorFilesLines
2022-01-28[lldb] [gdb-remote] Support getting siginfo via APIMichał Górny1-0/+20
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server. Differential Revision: https://reviews.llvm.org/D118055
2022-01-28Revert "[lldb] [gdb-remote] Support getting siginfo via API"Michał Górny1-20/+0
This reverts commit 1a8f60f5f5b8638a3e8e7fb31ba7ae9e17a7ff2d. The API requires further work.
2022-01-27[lldb] [gdb-remote] Support getting siginfo via APIMichał Górny1-0/+20
Add Thread::GetSiginfo() and SBThread::GetSiginfo() methods to retrieve the siginfo value from server. Differential Revision: https://reviews.llvm.org/D118055
2022-01-25[lldb] Make logging machinery type-safePavel Labath1-4/+4
This patch makes use of c++ type checking and scoped enums to make logging statements shorter and harder to misuse. Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process. Because it now carries type information we do not need to worry about matching a specific enum value with the right getter function -- the compiler will now do that for us. The main entry point for the logging machinery becomes the GetLog (template) function, which will obtain the correct Log object based on the enum type. It achieves this through another template function (LogChannelFor<T>), which must be specialized for each type, and should return the appropriate channel object. This patch also removes the ability to log a message if multiple categories are enabled simultaneously as it was unused and confusing. This patch does not actually remove any of the existing interfaces. The defines and log retrieval functions are left around as wrappers around the new interfaces. They will be removed in follow-up patch. Differential Revision: https://reviews.llvm.org/D117490
2021-01-15[LLDB] Add per-thread register infos shared pointer in gdb-remoteMuhammad Omair Javaid1-2/+10
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
2020-03-09[lldb] Return Unwinder& from Thread::GetUnwinderPavel Labath1-3/+1
The function always returns a valid object. Let the return type reflect that, and remove some null checks.
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann1-1/+1
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-11-07[lldb-server] Add setting to force 'g' packet useGuilherme Andrade1-4/+5
Following up on https://reviews.llvm.org/D62221, this change introduces the settings plugin.process.gdb-remote.use-g-packet-for-reading. When they are on, 'g' packets are used for reading registers. Using 'g' packets can improve performance by reducing the number of packets exchanged between client and server when a large number of registers needs to be fetched. Differential revision: https://reviews.llvm.org/D62931
2019-07-24[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere1-5/+3
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere1-2/+0
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
2019-02-11Use std::make_shared in LLDB (NFC)Jonas Devlieghere1-3/+5
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
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
2018-12-15Simplify Boolean expressionsJonas Devlieghere1-7/+4
This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
2018-08-07Move RegisterValue,Scalar,State from Core to UtilityPavel Labath1-1/+1
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
2018-07-10[windows] LLDB shows the wrong values when register read is executed at a ↵Stella Stamenova1-5/+5
frame other than zero Summary: This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495 The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it. Reviewers: asmith, zturner, aleksandr.urakov Reviewed By: aleksandr.urakov Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits Differential Revision: https://reviews.llvm.org/D49111 llvm-svn: 336732
2018-04-30Reflow paragraphs in comments.Adrian Prantl1-18/+16
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-03-20Move StringExtractorGDBRemote.h to the include folderPavel Labath1-1/+1
While trying to use this header I noticed that it is not in the include folder. Move it to there and update all #includes to reference that file correctly. llvm-svn: 327996
2017-11-13Move ArchSpec to the Utility modulePavel Labath1-1/+0
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
2017-03-04Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner1-1/+1
llvm-svn: 296943
2017-02-17Switch GDBRemoteLog to the new registration mechanismPavel Labath1-8/+6
llvm-svn: 295455
2017-02-02Move classes from Core -> Utility.Zachary Turner1-1/+1
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
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-312/+257
*** 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
2016-08-19Remove the last manually constructed packet from gdb-remote register context ↵Pavel Labath1-2/+2
+ 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
2016-01-12Changes to lldb and debugserver to reduce extraneous memory readsJason Molenda1-16/+91
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
2015-12-18The lldb side changes to go along with r255711 where a newJason Molenda1-0/+8
"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
2015-07-14Refactor Unix signals.Chaoren Lin1-2/+2
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
2015-06-25Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton1-6/+1
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
2015-06-23Implement the "qSymbol" packet in order to be able to read queue information ↵Greg Clayton1-7/+40
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
2015-06-23Revert "Reduced packet counts to the remote GDB server where possible."Chaoren Lin1-1/+6
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
2015-06-22Reduced packet counts to the remote GDB server where possible.Greg Clayton1-6/+1
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
2015-03-31Move several plugin to its own namespaceTamas Berghammer1-2/+3
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
2015-03-03Further reduce the header footprint of Process.hZachary Turner1-0/+1
No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
2014-06-13Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda1-0/+17
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
2014-04-25Add a new SBThread::GetQueue() method to get the queue that is Jason Molenda1-0/+16
currently associated with a given thread, on relevant targets. Change the queue detection code to verify that the queues associated with all live threads are included in the list. <rdar://problem/16411314> llvm-svn: 207160
2014-03-13Add a SBQueue::GetKind() method to retrieve the type of libdispatch queue ↵Jason Molenda1-0/+19
(serial or concurrent). <rdar://problem/7964505> llvm-svn: 203748
2014-02-05Change the Mac OS X SystemRuntime plugin from using the placeholderJason Molenda1-6/+7
libldi library to collect extended backtrace information; switch to the libBacktraceRecording library and its APIs. Complete the work of adding QueueItems to Queues and allow for the QueueItems to be interrogated about their extended backtraces in turn. There's still cleanup and documentation to do on this code but the code is functional and I it's a good time to get the work-in-progress checked in. <rdar://problem/15314027> llvm-svn: 200822
2013-11-04Roll back the changes I made in r193907 which created a new FrameJason Molenda1-1/+1
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
2013-11-02Add a new base class, Frame. It is a pure virtual function whichJason Molenda1-1/+1
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
2013-10-18Move the code which translates a dispatch_qaddr into aJason Molenda1-4/+30
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
2013-09-04Fixed detection of 'p' packet support in debugserver,Sean Callanan1-1/+1
by appending the thread ID to the test packet when debugserver requires it. This allows register writing (and, by extension, expressions) to work on Mac OS X. llvm-svn: 190007
2013-08-29Discover support of 'p' packet.Hafiz Abid Qadeer1-1/+2
Some stubs only support g/G packets for registers. This change makes sure that we check if remote stub supports 'p' packet before using it. llvm-svn: 189576
2013-05-09Changed the formerly pure virtual function:Greg Clayton1-45/+7
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
2013-05-07Reinstating r181091 and r181106 with fix for Linux regressions.Andrew Kaylor1-19/+38
llvm-svn: 181340
2013-05-07Temporarily reverting r181091 and r181106 due to the vast test breakage on ↵Ashok Thirumurthi1-38/+19
the Linux buildbots while we develop a better understanding of how to manage the thread lists in a platform-independant fashion. Reviewed by: Daniel Malea llvm-svn: 181323
2013-05-04After recent OperatingsSystem plug-in changes, the lldb_private::Process and ↵Greg Clayton1-19/+38
lldb_private::Thread subclasses were changed and the API was not respected properly. This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list. These changes keep the lldb_private::Process subclasses clean and no changes are required. llvm-svn: 181091
2013-05-01<rdar://problem/13700260>Greg Clayton1-30/+8
<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
2013-04-12<rdar://problem/13491977>Greg Clayton1-2/+6
Made some fixes to the OperatingSystemPython class: - If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread. - Cleaned up all the places where a thread inside a thread was causing problems llvm-svn: 179405
2013-03-27<rdar://problem/13521159>Greg Clayton1-1/+1
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2012-11-29Resolve printf formatting warnings on Linux:Daniel Malea1-1/+1
- use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-10-16Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two ↵Jim Ingham1-0/+3
breakpoints were set on consecutive addresses, the continue from the first breakpoint would skip the second. llvm-svn: 166000