Right. If you watch the lazy binding that happens the first time a symbol is called - at least on macOS - the loader does a lot of work, and calls various standard library functions and helper functions in its own library that aren't in any real sense trampolines. Actually, objc_msgSend can do the same when first binding. And of course this wouldn't work at all for things like the std::function trampoline. Plus, remember that for the most part these "trampolines" like the loader symbol ones or the objc_msgSend ones all happen in code that most users don't have debug information for. So relying on debug information to handle this really isn't workable.
Also, single-stepping is not fast, particularly when debugging a remote device. It's really the round-trip time that costs, but with single-stepping you get lots of that. We got really significant speed-ups in stepping by having lldb run from branch to branch using breakpoints rather than single-stepping through the line. So a method which relies on single stepping - or even running from branch to branch - through potentially lots of code - is not a good strategy. Jim > On Sep 25, 2019, at 12:46 PM, Nat! <n...@mulle-kybernetik.com> wrote: > > >> I don't think that is right for "step-in". As you said above, in the >> classic example of a trampoline: objc_msgSend you can't statically know the >> destination. So the DWARF can't help resolve this; you would still need to >> do the work the lldb trampoline classes do at runtime. >> > I was thinking along the line of the debugger looking examining the stack > frame after a step and if it is marked as artificial continuing to do "stepi" > until it hits a frame that isn't marked artificial. That would work for quite > a bit of code (probably most of mine :). But I can see that the scheme would > fail, if the trampoline code needs to execute a stdlib function or some such > (maybe on a cache miss). > > Ciao > Nat! > > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
