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

[Jim Ingham via lldb-dev]

At some point it would be good to add trampoline support at the Python level.  You can produce scripted thread plans now - and the trampoline mechanism just returns a thread plan to step through the trampoline...  It would be neat to be able to support other systems without having to build them into lldb.  But that's off-topic.  Glad you got that part working...

lldb can step through trampolines (and step back out again in some cases).  But there isn't any support for suppressing the printing of frames.  

I don't think it is a good idea for lldb to lie to the user and pretend that frames that do exist don't exist.  But I think it's fine to have a mode where lldb suppresses printing some frames to reduce noise.  As you showed in your example, the frame numbering would still indicate the presence of the frames, and presumably there would be a "bt --full" or something to show them all.  But there isn't support for this at present.

One way to add this is to use the "Frame Recognizers" Kuba added to lldb recently.  The use he had for them was to produce artificial variables for frames you don't have debug information for.  But one of the other jobs I had envisioned for frame recognizers was to mark frames as uninteresting for printing.  Then you could hook up "bt" to suppress frames that the recognizer marked this way.  Since you can add recognizers in Python, this is a fairly attractive way to go, since people could adjust their printing to suppress frames not interesting to them.  And of course, as Adrian suggested, recognizers could consult the debug info as well to suppress DW_AT_artificial and DW_AT_trampoline.

Xcode has a neat implementation of this stack compaction idea, where it keeps the first and last call into a library with out debug information, and suppresses the ones in between.  The first call is going to be the public API that your code called, so seeing it is helpful.  But then the ones in between are generally internal implementation, and so not as interesting to users of the library.  For that you'd have to have a "stack pattern" recognizer, not a frame by frame recognizer.  So it wouldn't fit naturally into Kuba's work.  

It also isn't what you need, since you want to suppress all the recognized frames.  So for your purposes, adding "should suppress" to the recognizers and using that info in backtraces should suffice.

Jim

> On Sep 23, 2019, at 2:12 AM, Nat! via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> When I am using `bt` to look at my backtrace, I get for a method call breakpoint in `+[Hello printName:version:]` a stacktrace like this (with my custom Objective-C runtime):
> 
> ```
>   * frame #0: 0x00000000004179b3 test-debugger`+[Hello printName:version:](self=Hello, _cmd=<no value available>, _param=0x00007fffffffd8a8, name=<unavailable>, version=<unavailable>) at main.m:21:21
>     frame #1: 0x00000000004bb659 test-debugger`_mulle_objc_object_call_class_nofail(obj=0x000000000066a200, methodid=3009363030, parameter=0x00007fffffffd8a8, cls=0x000000000066a3e0) at mulle-objc-call.c:668:13
>     frame #2: 0x00000000004bbe60 test-debugger`_mulle_objc_object_call_class(obj=0x000000000066a200, methodid=3009363030, parameter=0x00007fffffffd8a8, cls=0x000000000066a3e0) at mulle-objc-call.c:939:18
>     frame #3: 0x00000000004bcb63 test-debugger`_mulle_objc_object_call_class_needcache(obj=0x000000000066a200, methodid=3009363030, parameter=0x00007fffffffd8a8, cls=0x000000000066a3e0) at mulle-objc-call.c:1320:13
>     frame #4: 0x00000000004bcf61 test-debugger`mulle_objc_object_call(obj=0x000000000066a200, methodid=3009363030, parameter=0x00007fffffffd8a8) at mulle-objc-call.c:1379:13
>     frame #5: 0x0000000000417a28 test-debugger`main(argc=1, argv=0x00007fffffffd9c8) at main.m:29:4
> ```
> 
> I have my Plugin/LanguageRuntime/ObjC/MulleObjC added to lldb and it is working fine for stepping through from "main" to "-[Hello printName:version:]" directly. Now I wonder, if there are provisions in lldb to extend this idea of trampoline hiding to stacktraces (preferably as an option), so the stacktrace would look like this:
> 
> 
> ```
>   * frame #0: 0x00000000004179b3 test-debugger`+[Hello printName:version:](self=Hello, _cmd=<no value available>, _param=0x00007fffffffd8a8, name=<unavailable>, version=<unavailable>) at main.m:21:21
>    frame #5: 0x0000000000417a28 test-debugger`main(argc=1, argv=0x00007fffffffd9c8) at main.m:29:4
> ```
> 
> Ciao
>     Nat!
> 
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev