[lldb-dev] Hiding trampoline functions from the backtrace, is it possible ?
lldb-dev at lists.llvm.org
Wed Sep 25 05:51:40 PDT 2019
> -----Original Message-----
> From: lldb-dev [mailto:lldb-dev-bounces at lists.llvm.org] On Behalf Of Jim
> Ingham via lldb-dev
> Sent: Tuesday, September 24, 2019 4:19 PM
> To: Nat!
> Cc: LLDB
> Subject: Re: [lldb-dev] Hiding trampoline functions from the backtrace, is
> it possible ?
> > 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.
> >> Jim
> > Yes.
> > 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
Clang puts DW_AT_artificial on implicit member functions, which tend to be
inlined due to their simplicity; explicit functions marked as 'inline' in
the source would not be flagged as artificial. There's no direct link
between inline and artifical.
I grepped for "trampoline" in Clang source; it occurs only in comments,
and never with respect to functions spontaneously created by the compiler.
If they're there, they're called something else.
> > 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
> > 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.
> > Ciao
> > Nat!
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
More information about the lldb-dev