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
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
The original revision (r329891) was reverted because the associated
tests ran into a deadlock on the Linux bots. That problem was resolved
by r330002.
llvm-svn: 330005
When we're dealing with virtual (memory) threads created by the OS
plugins, there's no guarantee that the real thread and the backing
thread share a protocol ID. Instead, we should iterate over the memory
threads to find the virtual thread that is backed by the current real
thread.
Differential revision: https://reviews.llvm.org/D45497
rdar://36485830
llvm-svn: 329891
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
ThreadList had an assignment operator that didn't lock the "rhs" thread list object. This means a thread list can be mutated while it is being copied.
The copy constructor calls the assignment operator as well. So this fixes the unsafe threaded access to ThreadList which we believe is responsible for a lot of crashes.
<rdar://problem/28075793>
llvm-svn: 289100
*** 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
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.
I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.
<rdar://problem/24978569>
llvm-svn: 263326
Summary:
On Linux, if a thread-specific conditional breakpoint was hit, it
won't necessarily be the thread that hit the breakpoint itself that
evaluates the conditional expression, so the thread that hit the
breakpoint could still be asked to stop, even though it hasn't been
allowed to run since the previous stop.
Reviewers: sivachandra, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14472
llvm-svn: 252391
The Go runtime schedules user level threads (goroutines) across real threads.
This adds an OS plugin to create memory threads for goroutines.
It supports the 1.4 and 1.5 go runtime.
Differential Revision: http://reviews.llvm.org/D5871
llvm-svn: 247852
Specifically, there were some functions for converting enums
to strings and a function for matching a string using a specific
matching algorithm. This moves those functions to more appropriate
headers in lldb/Utility and updates references to include the
new headers.
llvm-svn: 232673
but by the time we go to halt, it has already stopped by hitting the
function end breakpoint. That wasn't being shown to the threads so the
Function call thread plan didn't know its job was done.
<rdar://problem/16515785>
llvm-svn: 205803
control to the user anyway. This was put in to handle monitors that would say there was no
stop reason when you first attached to them. But it broke the case where you hit a thread specific
breakpoint on many threads, but NOT the one specified in the breakpoint. I work around this
by only doing the junky override when the StopID is 0 - i.e. on first attach.
This commit also adds a test for thread specific breakpoints.
llvm-svn: 199290
This re-submission of this patch fixes a problem where the code sometimes caused a deadlock. The Process::SetPrivateState method was locking the Process::m_private_state variable and then later calling ThreadList::DidStop, which locks the ThreadList mutex. Other methods in ThreadList which were being called from other threads lock the ThreadList mutex and then call Process::GetPrivateState which locks the Process::m_private_state mutex. To avoid deadlocks, Process::SetPrivateState now locks the ThreadList mutex before locking the Process::m_private_state mutex.
llvm-svn: 181609
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
value. This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh! I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.
Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming. That allows
us to handle resuming in a more controlled fashion.
Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--
M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M include/lldb/Target/ThreadList.h
M include/lldb/Target/ThreadPlanStepOut.h
M include/lldb/Target/Thread.h
M include/lldb/Target/ThreadPlanBase.h
M include/lldb/Target/ThreadPlanStepThrough.h
M include/lldb/Target/ThreadPlanStepInstruction.h
M include/lldb/Target/ThreadPlanStepInRange.h
M include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M include/lldb/Target/ThreadPlanStepUntil.h
M include/lldb/Target/StopInfo.h
M include/lldb/Target/Process.h
M include/lldb/Target/ThreadPlanRunToAddress.h
M include/lldb/Target/ThreadPlan.h
M include/lldb/Target/ThreadPlanCallFunction.h
M include/lldb/Target/ThreadPlanStepOverRange.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M source/Target/StopInfo.cpp
M source/Target/Process.cpp
M source/Target/ThreadPlanRunToAddress.cpp
M source/Target/ThreadPlan.cpp
M source/Target/ThreadPlanCallFunction.cpp
M source/Target/ThreadPlanStepOverRange.cpp
M source/Target/ThreadList.cpp
M source/Target/ThreadPlanStepOut.cpp
M source/Target/Thread.cpp
M source/Target/ThreadPlanBase.cpp
M source/Target/ThreadPlanStepThrough.cpp
M source/Target/ThreadPlanStepInstruction.cpp
M source/Target/ThreadPlanStepInRange.cpp
M source/Target/ThreadPlanStepOverBreakpoint.cpp
M source/Target/ThreadPlanStepUntil.cpp
M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme
llvm-svn: 181381
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
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
<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
ShouldStop on the threads, which might destroy information needed to correctly compute another
thread's StopInfo.
<rdar://problem/13664026>
llvm-svn: 179641
Partial fix for the above radar.
Call ThreadList::Clear() in the ThreadList destructor so if any other threads currently have the thread list mutex, we won't destroy the list for them while they are using it. ThreadList::Clear() takes the mutex and clears the thread list contents.
llvm-svn: 178257
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
on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an
assert and dies immediately. So for now its off.
llvm-svn: 163044
<rdar://problem/11455913>
"target symbol add" should flush the cached frames
"register write" should flush the thread state in case registers modifications change stack
llvm-svn: 157042
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.
Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.
llvm-svn: 150154
Adrian Prantl