summaryrefslogtreecommitdiff
path: root/lldb/source/Target/ExecutionContext.cpp
AgeCommit message (Collapse)Author
2025-09-23[lldb] Rework how we pass the execution context to the statusline (#159887)Jonas Devlieghere
Currently, we always pass the "selected" execution context to the statusline. When handling a process or thread event, we can be more precise, and build an execution context from the event data. This PR also adopts the new `StoppedExecutionContext` that was recently introduced.
2025-08-11[lldb][NFC] Address follow up comments in ExecutionContext (#153110)Felipe de Azevedo Piovezan
The PR https://github.com/llvm/llvm-project/pull/152020 got merged by accident. This commit addresses some follow up review comments.
2025-08-11[lldb] Guard SBFrame/SBThread methods against running processes (#152020)Felipe de Azevedo Piovezan
Prior to this patch, SBFrame/SBThread methods exhibit racy behavior if called while the process is running, because they do not lock the `Process::RetRunLock` mutex. If they did, they would fail, correctly identifying that the process is not running. Some methods _attempt_ to protect against this with the pattern: ``` ExecutionContext exe_ctx(m_opaque_sp.get(), lock); // this is a different lock Process *process = exe_ctx.GetProcessPtr(); if (process) { Process::StopLocker stop_locker; if (stop_locker.TryLock(&process->GetRunLock())) .... do work ... ``` However, this is also racy: the constructor of `ExecutionContext` will access the frame list, which is something that can only be done once the process is stopped. With this patch: 1. The constructor of `ExecutionContext` now expects a `ProcessRunLock` as an argument. It attempts to lock the run lock, and only fills in information about frames and threads if the lock can be acquired. Callers of the constructor are expected to check the lock. 2. All uses of ExecutionContext are adjusted to conform to the above. 3. The SBThread.cpp-defined helper function ResumeNewPlan now expects a locked ProcessRunLock as _proof_ that the execution is stopped. It will unlock the mutex prior to resuming the process. This commit exposes many opportunities for early-returns, but these would increase the diff of this patch and distract from the important changes, so we opt not to do it here.
2025-08-04[lldb][nfc] Use delegating ctor for ExecutionContext (#151987)Felipe de Azevedo Piovezan
The ctor that takes a reference to ExecutionContextRef can be implemented in terms of the ctor that takes a pointer to that object, removing code duplication.
2023-04-21Make sure SelectMostRelevantFrame happens only when returning to the user.Jim Ingham
This is a user facing action, it is meant to focus the user's attention on something other than the 0th frame when you stop somewhere where that's helpful. For instance, stopping in pthread_kill after an assert will select the assert frame. This is not something you want to have happen internally in lldb, both because internally you really don't want the selected frame changing out from under you, and because the recognizers can do arbitrary work, and that can cause deadlocks or other unexpected behavior. However, it's not something that the current code does explicitly after a stop has been delivered, it's expected to happen implicitly as part of stopping. I changing this to call SMRF explicitly after a user stop, but that got pretty ugly quickly. So I added a bool to control whether to run this and audited all the current uses to determine whether we're returning to the user or not. Differential Revision: https://reviews.llvm.org/D148863
2022-03-31[LLDB] Applying clang-tidy modernize-use-equals-default over LLDBShafik Yaghmour
Applied modernize-use-equals-default clang-tidy check over LLDB. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121844
2022-03-14[LLDB] Applying clang-tidy modernize-use-default-member-init over LLDBShafik Yaghmour
Applied modernize-use-default-member-init clang-tidy check over LLDB. It appears in many files we had already switched to in class member init but never updated the constructors to reflect that. This check is already present in the lldb/.clang-tidy config. Differential Revision: https://reviews.llvm.org/D121481
2021-06-09[lldb] Use C++11 default member initializersJonas Devlieghere
This converts a default constructor's member initializers into C++11 default member initializers. This patch was automatically generated with clang-tidy and the modernize-use-default-member-init check. $ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix This is a mass-refactoring patch and this commit will be added to .git-blame-ignore-revs. Differential revision: https://reviews.llvm.org/D103483
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann
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-08-07[ExecutionContext] Return the target/process byte order.Jonas Devlieghere
Currently ExecutionContext::GetByteOrder() always returns the host byte order. This seems like a simple mistake: the return keyword appears to have been omitted by accident. This patch fixes that and adds a unit test. Bugreport: https://llvm.org/PR37950 Differential revision: https://reviews.llvm.org/D48704 llvm-svn: 368181
2019-03-05Remove tautological #ifdefs (NFC)Adrian Prantl
Differential Revision: https://reviews.llvm.org/D58838 llvm-svn: 355457
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
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-11-11Remove header grouping comments.Jonas Devlieghere
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
2018-08-07Move RegisterValue,Scalar,State from Core to UtilityPavel Labath
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-04-30Reflow paragraphs in comments.Adrian Prantl
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
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone
*** 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-05-19second pass over removal of Mutex and ConditionSaleem Abdulrasool
llvm-svn: 270024
2016-02-18Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes.Eugene Zelenko
llvm-svn: 261179
2015-11-07Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener
Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
2015-02-25Add missing "return" statements.Hafiz Abid Qadeer
ExecutionContext::GetAddressByteSize() was calling GettAddressByteSize () on Target and Process class but was ignoring the return type. I have added the missing return. No regression in the test suite. Committed as obvious. llvm-svn: 230502
2015-02-12Make a more complete fix for always supplying an execution context when ↵Greg Clayton
getting byte sizes from types. There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime. Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use. llvm-svn: 228892
2015-01-19Fix a race condition where you could set the selected thread & target in theJim Ingham
CommandInterpreter's execution context AFTER the process had started running and before it initially stopped. Also fixed one test case that was implicitly using this (and an abuse of the async mode) to accidentally succeed. <rdar://problem/16814726> llvm-svn: 226528
2014-01-27Merging the iohandler branch back into main. Greg Clayton
The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
2013-11-04Roll back the changes I made in r193907 which created a new FrameJason Molenda
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 Molenda
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-08<rdar://problem/14028923>Enrico Granata
Implement SBTarget::CreateValueFromAddress() with a behavior equivalent to SBValue::CreateValueFromAddress() (but without the need to grab an SBValue first just as a starting point to make up another SBValue out of whole cloth) llvm-svn: 192239
2013-05-24<rdar://problem/13643315> Greg Clayton
Fixed performance issues that arose after changing SBTarget, SBProcess, SBThread and SBFrame over to using a std::shared_ptr to a ExecutionContextRef. The ExecutionContextRef doesn't store a std::weak_ptr to a stack frame because stack frames often get replaced with new version, so it held onto a StackID object that would allow us to ask the thread each time for the frame for the StackID. The linear function was too slow for large recursive stacks. We also fixed an issue where anytime the std::shared_ptr<ExecutionContextRef> in any SBTarget, SBProcess, SBThread objects was turned into an ExecutionContext object, it would try to resolve all items in the ExecutionContext which are shared pointers. Even if the StackID in the ExecutionContextRef was invalid, it was looking through all frames in every thread. This causes a lot of unnecessary frame accesses. llvm-svn: 182627
2013-03-15<rdar://problem/13194155>Greg Clayton
Variables view out of sync with lldb in Xcode is now fixed. Depending on what happened stack frames could get out of date and a stale shared pointer (one that is no longer a current frame in a thread) could end up being used. Now we don't store a weak_ptr to a frame in the ExecutionContextRef class, we just store its stack ID and we always regrab the frame from the thread by stack ID. llvm-svn: 177208
2013-03-15<rdar://problem/13194155>Enrico Granata
Fixing an issue where threads and frames could get out of sync and cause ValueObjects to fail to retrieve their values correctly llvm-svn: 177166
2012-08-22Rework how the API mutex is acquired when filling out an ExecutionContext ↵Jim Ingham
from an ExecutionContextRef, particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another command Destroy's the Thread you've just gotten. Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects. Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing that scope has been destroyed. Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value. <rdar://problem/11995490> llvm-svn: 162401
2012-07-30Don't set the thread when adopting selected execution context entries, and ↵Greg Clayton
use the "lldb_private::StateIsStoppedState(StateType, bool)" function to tell if the state is stopped. llvm-svn: 161000
2012-07-26Don't have ExecutionContextRef::SetTargetPtr fill in the frameJason Molenda
information if we're not stopped. This could try to read registers etc when the process is still running and debug builds of lldb would assert down in GDBRemoteRegisterContext.cpp ReadRegisterBytes because we couldn't get the sequence mutex for talking to the remote system. Non-debug builds would just silently fail when doing this. <rdar://problem/11941758> llvm-svn: 160829
2012-04-05Added a new Host class: ReadWriteLockGreg Clayton
This abstracts read/write locks on the current host system. It is currently backed by pthread_rwlock_t objects so it should work on all unix systems. We also need a way to control multi-threaded access to the process through the public API when it is running. For example it isn't a good idea to try and get stack frames while the process is running. To implement this, the lldb_private::Process class now contains a ReadWriteLock member variable named m_run_lock which is used to control the public process state. The public process state represents the state of the process as the client knows it. The private is used to control the actual current process state. So the public state of the process can be stopped, yet the private state can be running when evaluating an expression for example. Adding the read/write lock where readers are clients that want the process to stay stopped, and writers are clients that run the process, allows us to accurately control multi-threaded access to the process. Switched the SBThread and SBFrame over to us shared pointers to the ExecutionContextRef class instead of making their own class to track this. This fixed an issue with assigning on SBFrame to another and will also centralize the code that tracks weak references to execution context objects into one location. llvm-svn: 154099
2012-04-04<rdar://problem/11184458>Greg Clayton
Found an issue where we might still have shared pointer references to lldb_private::Thread objects where the object itself is not valid and has been removed from the Process. When a thread is removed from a process, it will call Thread::DestroyThread() which well set a boolean member variable which is exposed now via: bool Thread::IsValid() const; We then check the thread validity before handing out a shared pointer. llvm-svn: 154048
2012-02-21Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptrGreg Clayton
objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. llvm-svn: 151009
2012-02-18The second part in thread hardening the internals of LLDB where we makeGreg Clayton
the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-17This checking is part one of trying to add some threading safety to ourGreg Clayton
internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-01-29Switching back to using std::tr1::shared_ptr. We originally switched awayGreg Clayton
due to RTTI worries since llvm and clang don't use RTTI, but I was able to switch back with no issues as far as I can tell. Once the RTTI issue wasn't an issue, we were looking for a way to properly track weak pointers to objects to solve some of the threading issues we have been running into which naturally led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared pointer from just a pointer, which is also easily solved using the std::tr1::enable_shared_from_this class. The main reason for this move back is so we can start properly having weak references to objects. Currently a lldb_private::Thread class has a refrence to its parent lldb_private::Process. This doesn't work well when we now hand out a SBThread object that contains a shared pointer to a lldb_private::Thread as this SBThread can be held onto by external clients and if they end up using one of these objects we can easily crash. So the next task is to start adopting std::tr1::weak_ptr where ever it makes sense which we can do with lldb_private::Debugger, lldb_private::Target, lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and many more objects now that they are no longer using intrusive ref counted pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive pointers). llvm-svn: 149207
2011-09-22Converted the lldb_private::Process over to use the intrusiveGreg Clayton
shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-07-07Added "target variable" command that allows introspection of globalGreg Clayton
variables prior to running your binary. Zero filled sections now get section data correctly filled with zeroes when Target::ReadMemory reads from the object file section data. Added new option groups and option values for file lists. I still need to hook up all of the options to "target variable" to allow more complete introspection by file and shlib. Added the ability for ValueObjectVariable objects to be created with only the target as the execution context. This allows them to be read from the object files through Target::ReadMemory(...). Added a "virtual Module * GetModule()" function to the ValueObject class. By default it will look to the parent variable object and return its module. The module is needed when we have global variables that have file addresses (virtual addresses that are specific to module object files) and in turn allows global variables to be displayed prior to running. Removed all of the unused proxy object support that bit rotted in lldb_private::Value. Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code with the more efficient "FileSpec::Equal (lhs, rhs)". Improved logging in GDB remote plug-in. llvm-svn: 134579
2011-04-26Changed the emulate instruction function to take emulate options whichGreg Clayton
are defined as enumerations. Current bits include: eEmulateInstructionOptionAutoAdvancePC eEmulateInstructionOptionIgnoreConditions Modified the EmulateInstruction class to have a few more pure virtuals that can help clients understand how many instructions the emulator can handle: virtual bool SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0; Where instruction types are defined as: //------------------------------------------------------------------ /// Instruction types //------------------------------------------------------------------ typedef enum InstructionType { eInstructionTypeAny, // Support for any instructions at all (at least one) eInstructionTypePrologueEpilogue, // All prologue and epilogue instructons that push and pop register values and modify sp/fp eInstructionTypePCModifying, // Any instruction that modifies the program counter/instruction pointer eInstructionTypeAll // All instructions of any kind } InstructionType; This allows use to tell what an emulator can do and also allows us to request these abilities when we are finding the plug-in interface. Added the ability for an EmulateInstruction class to get the register names for any registers that are part of the emulation. This helps with being able to dump and log effectively. The UnwindAssembly class now stores the architecture it was created with in case it is needed later in the unwinding process. Added a function that can tell us DWARF register names for ARM that goes along with the source/Utility/ARM_DWARF_Registers.h file: source/Utility/ARM_DWARF_Registers.c Took some of plug-ins out of the lldb_private namespace. llvm-svn: 130189
2011-01-06Fixed issues with RegisterContext classes and the subclasses. There wasGreg Clayton
an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2010-10-04There are now to new "settings set" variables that live in each debuggerGreg Clayton
instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-08-26Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to ↵Jim Ingham
"Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected. llvm-svn: 112221
2010-06-08Initial checkin of lldb code from internal Apple repo.Chris Lattner
llvm-svn: 105619