> -----Original Message----- > From: lldb-dev [mailto:lldb-dev-boun...@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- > d...@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@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
