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

[via lldb-dev]

> -----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
> anyway.

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.
--paulr

> >
> > 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.
> 
> Jim
> 
> 
> >
> > 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev