[lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?
Jim Ingham via lldb-dev
lldb-dev at lists.llvm.org
Tue Sep 24 13:19:22 PDT 2019
> On Sep 24, 2019, at 11:36 AM, Nat! via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> On 24.09.19 19:28, Jim Ingham wrote:
>> We've had many requests to elide some classes of entries in backtraces - like to mirror the Xcode display I mentioned previously. Most of these requests don't depend on the functions being marked artificial. So if we're going to do this, something more general than just "marked artificial" -> elided anyway.
> Having done a little further research... Artificial won't work for general cases anyway, since it's restricted to inline code (for some reason) on gcc and clang. I wonder why, since for a function the only real effect is to emit DW_AT_artificial (AFAIK). The restriction seems arbitrary and DWARF wouldn't mind.. But the compilers do, so it seems out anyway.
> DW_AT_trampoline isn't supported by llvm. As I read the description of DW_AT_trampoline, its more like a hardcoded vector (a->b), so not useful for cases like objc_msgSend, where you don't know the destination a priori.
> If I look at the DWARF spec, I don't see any other way to mark a function as "boring". I still think this would be a good thing, as this would be useful for other debuggers as well, which could instantly work. Also a lot of code in the lldb Trampoline classes, for step-in and step-out could probably just be removed.
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.
step-out past trampolines could just "keep stepping past boring functions". There's no need to support this for ObjC - at least the Apple & NeXT versions - since the dispatch function is a tail call function. But we do do something like for Swift. But that part is very little code compared to figuring how to step in correctly.
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev