wrong answer. Plus, it's useful in some places to have a way to force the full stack to be created even in the face of interruption. Moreover, most of the time when you're just getting frames, you don't need to know the number of frames in the stack to start with. You just keep calling Thread::GetStackFrameAtIndex(index++) and when you get a null StackFrameSP back, you're done. That's also more amenable to interruption if you are doing some work frame by frame. So this patch makes GetStackFrameCount always return the full count, suspending interruption. I also went through all the places that use GetStackFrameCount to make sure that they really needed the full stack walk. In many cases, they did not. For instance frame select -r 10 was getting the number of frames just to check whether cur_frame_idx + 10 was within the stack. It's better in that case to see if that frame exists first, since that doesn't force a full stack walk, and only deal with walking off the end of the stack if it doesn't... I also added a test for some of these behaviors. Differential Revision: https://reviews.llvm.org/D150236
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
SelectMostRelevantFrame triggers the StackFrameRecognizer construction, which can run arbitrary Python code, call expressions etc. WillStop gets called on every private stop while the recognizers are a user-facing feature, so first off doing this work on every stop is inefficient. But more importantly, you can get in to situations where the recognizer causes an expression to get run, then when we fetch the stop event at the end of the expression evaluation, we call WillStop again on the expression handling thread, which will do the same StackFrameRecognizer work again. If anyone is locking along that path, you will end up with a deadlock between the two threads. The example that brought this to my attention was the objc_exception_throw recognizer which can cause the objc runtime introspection functions to get run, and those take a lock in AppleObjCRuntimeV2::DynamicClassInfoExtractor::UpdateISAToDescriptorMap along this path, so the second thread servicing the expression deadlocks against the first thread waiting for the expression to complete. It makes more sense to have the frame recognizers run on demand, either when someone asks for the variables for the frame, or when someone does GetSelectedFrame. The former already worked that way, the only reason this was being done in WillStop was because the StackFrameRecognizers can change the SelectedFrame, so you needed to run them before the anyone requested the SelectedFrame. This patch moves SelectMostRelevantFrame to StackFrameList, and runs it when GetSelectedFrame is called for the first time on a given stop. If you call SetSelectedFrame before GetSelectedFrame, then you should NOT run the recognizer & change the frame out from under you. This patch also makes that work. There were already tests for this behavior, and for the feature that caused the hang, but the hang is racy, and it doesn't trigger all the time, so I don't have a way to test that explicitly. One more detail: it's actually pretty easy to end up calling GetSelectedFrame, for instance if you ask for the best ExecutionContext from an ExecutionContextRef it will fill the StackFrame with the result of GetSelectedFrame and that would still have the same problems if this happens on the Private State Thread. So this patch also short-circuits SelectMostRelevantFrame if run on the that thread. I can't think of any reason the computations that go on on the Private State Thread would actually want the SelectedFrame - that's a user-facing concept, so avoiding that complication is the best way to go. rdar://107643231 Differential revision: https://reviews.llvm.org/D147753
Command Interpreter mechanism. Differential Revision: https://reviews.llvm.org/D145136
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
Introduce three new stop reasons for fork, vfork and vforkdone events. This includes server support for serializing fork/vfork events into gdb-remote protocol. The stop infos for the two base events take a pair of PID and TID for the newly forked process. Differential Revision: https://reviews.llvm.org/D100196
That code is unused since it's check-in in 2010 (and I believe it would leak memory when called as it releases the passed unique_ptr), so let's delete it. Reviewed By: vsk Differential Revision: https://reviews.llvm.org/D100212
Add calls into LanguageRuntime when finding the unwind method to use out of the 0th (currently executing) stack frame. Allow for the LanguageRuntimes to indicate if this stack frames should be treated like a zeroth-frame -- symbolication should be done based on the saved pc address, not decremented like normal ABI function calls. Add methods to RegisterContext and StackFrame to get a pc value suitable for symbolication, to reduce the number of places in lldb where we decrement the saved pc values before symbolication. <rdar://problem/70398009> Differential Revision: https://reviews.llvm.org/D97644