[lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?

[Jim Ingham via lldb-dev]

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! <nat at 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!
> 
>