[PATCH] D65035: [DebugInfo] Don't emit incorrect descriptions of thunk params (PR42627)

[Vedant Kumar via Phabricator via llvm-commits]

vsk added a comment.

In D65035#1615888 <https://reviews.llvm.org/D65035#1615888>, @dblaikie wrote:

> In D65035#1615833 <https://reviews.llvm.org/D65035#1615833>, @aprantl wrote:
>
> > In D65035#1615819 <https://reviews.llvm.org/D65035#1615819>, @dblaikie wrote:
> >
> > > In D65035#1615787 <https://reviews.llvm.org/D65035#1615787>, @aprantl wrote:
> > >
> > > > It's likely better for the tools to know where each function starts *and ends*.
> > >
> > >
> > > __attribute__((nodebug)) breaks that invariant (& I think there's other functions we emit without debug info too - maybe some things to do with global ctors?)
> >
> >
> > Correct, and the tools need to fall back to heuristics in these cases. I don't know whether this causes any problems in practice.
> >
> > >> More importantly though, if we don't generate debug info for the thunk, can we describe the function itself after it became inlined into the thunk?
> > > 
> > > Not really, no - and GCC doesn't describe the inlining either. A backtrace would demangle the name of the thunk & that's about all it could show there.
> >
> > *That* sounds like a good reason to keep the debug info for the thunks around.
>
>
> Not sure I follow why demangling the symbol would result in a worse user experience than the debug info? About the only thing in the debug info is the mangled name that's in the symbol table too.


Oh, wouldn't the debugger lose the ability to synthesize an [inlined] frame for whatever is inlined into the thunk?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65035/new/

https://reviews.llvm.org/D65035