This is really an orthogonal problem to the thread plans. They are about answering the question "how do I get from A to B?". But you want to get the right answer to "If I land in B, do I want to stop there?" This sort of question is answered with the "ShouldStopHere" mechanism (see source/Target/ThreadPlanShouldStopHere.cpp). Then the Thread Plans will invoke this mechanism whenever they are about to stop and return control to the user, and the should stop here will decide whether to stop, and if you aren't going to stop, how to get out of the "bad" place.
I had to solve pretty much your problem for Swift thunks, which are much like your ObjC dispatch functions. Apparently that's a bit of code I missed when we were moving the generic changes for swift back to llvm.org. If you look at the Swift version of lldb: https://github.com/apple/swift-lldb/blob/stable/source/Target/ThreadPlanShouldStopHere.cpp You will see I added this bit to the DefaultShouldStopHereCallback (around line 88): // Check whether the frame we are in is a language runtime thunk, only for // step out: if (operation == eFrameCompareOlder) { Symbol *symbol = frame->GetSymbolContext(eSymbolContextSymbol).symbol; if (symbol) { LanguageRuntime *language_runtime; bool is_thunk = false; ProcessSP process_sp(current_plan->GetThread().GetProcess()); enum LanguageType languages_to_try[] = { eLanguageTypeSwift, eLanguageTypeObjC, eLanguageTypeC_plus_plus}; for (enum LanguageType language : languages_to_try) { language_runtime = process_sp->GetLanguageRuntime(language); if (language_runtime) is_thunk = language_runtime->IsSymbolARuntimeThunk(*symbol); if (is_thunk) { should_stop_here = false; break; } } } } I am pretty sure you should just be able to add this directly to the llvm.org lldb, and then have your LanguageRuntime reply true to the IsSymbolARuntimeThunk when the symbol is your dispatch function. Then the rest of the machinery will take care of getting you out of there. Jim > On May 19, 2017, at 2:40 PM, Nat! via lldb-dev <lldb-dev@lists.llvm.org> > wrote: > > I adapted the AppleObjcTrampolineHandler to my runtime. It works in as > much as that the debugger steps over my intermediate C functions and > breaks in the targetted method. > > Unfortunately when I step out of the method, I am not back at the ObjC > call (0x0000000100000ebf) but instead in my intermediate function. I > think this is, because I am not using trampolines (jumps) but plain C > functions. > > When I turn on `log enabled lldb step` and watch what is hapenning when > lldb steps through to -[foo class] (0x0000000100000df0) > I can see this at one point in time on the thread plan stack: > > ``` > thread #1: tid = 0x8c74: > Active plan stack: > Element 0: Base thread plan. > Element 1: Stepping in through line class.m:44 using > ranges:[0x0000000100000ea6-0x0000000100000ebf). > ******** > Element 2: Stepping through trampoline code from: > 0x0000000100000f42 with backstop breakpoint ID: -5 at address: > 0x0000000100000ebf > ******** > Element 3: Stepping to implementation of ObjC method - obj: > 0x100001158, isa: 0x100001130, sel: 0x7fff91f58a12 > Element 4: Run to address: 0x0000000100000df0 using breakpoint: -9 - > ``` > > There is a backstop breakpoint -5 at the address 0x0000000100000ebf. > Fine. But then, when the start of my method -[foo class] is reached, > the trampoline handler is popped and the breakpoint vanishes!. I need to > somehow "prolong" this backstop breakpoint. > > If I were to add a breakpoint to the return address > (0x0000000100000f42), I would lose the functionality, that "continue" > just continues w/o breaking on the backstop. So maybe I need to push > something ahead of the "step through" on the ThreadPlan stack but what ? > > Ciao > Nat! > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
