[PATCH] D146595: [clang] Add clang trampoline_mangled_target attribute

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D146595#4218040 <https://reviews.llvm.org/D146595#4218040>, @augusto2112 wrote:

>>>> What would happen if, instead, these trampolining functions were annotated nodebug? I guess then you wouldn't have the top level one as an entry point for the user, as there would be no debug info for it?
>>>
>>> These trampoline functions can call other functions as part of their setup, so annotating them with nodebug wouldn't guarantee that the debugger would be able to step through to the correct place. Additionally, you wouldn't be able to refer to them in LLDB expression evaluation either.
>>
>> Oh, that's a bit worrying - that these aren't trampolines in the sort of lower-level sense, only in a high level sense.
>>
>> Is the ability to debug these functions under some debugger flag ("show me intermediate steps/implementation details") a priority? Would it be OK if that were only available with a rebuild (ie: maybe didn't need to be represented in DWARF - this would also allow debug info to be smaller & not having to describe these transparent/implementation detail functions)?
>
> You mean step in the trampoline? It'd be nice, but not absolutely required. The main issue would be not being able to evaluate expressions though.

Right - yep yep.

>> Is there a single public entry point in most cases? How bad would it be if the implementation functions were all nodebug, but the public entry point and underlying function had debug info? Would that provide most/enough of the benefits you're after?
>
> Let me make sure I understand your suggestion, you mean we'd have three functions?
>
>   void target() {
>     // do stuff
>   }
>   
>   // attribute (nodebug)
>   void trampoline() {
>     // do setup
>     target()
>     // do cleanup
>   }
>   
>   void entrypoint() {
>     trampoline()
>   }
>
> Wouldn't users still have to step into the compiler generated `entrypoint`, and step in more to get to `target`?

Yep - wondering just how bad that'd be - how much abstraction you're trying to get past, etc.

> Also, depending the complexity of the trampoline algorithm, a step in still isn't guaranteed to stop in the `target` function: I think, as it's implemented right now, LLDB stepping into a function with no debug info will try to follow the first function call, and step out if that isn't somewhere with no debug info. We //could// change the step in algorithm, but a function with no debug info isn't necessarily a trampoline, and could have a chain of calls to other functions without debug info as well, and having the debugger stop at every one of those calls could be pretty expensive. This solution would be more performant, as we could set a private breakpoint in the `target` and continue the program.

True - being unable to tell whether there's something interesting in there or not does complicate things.

I'm coming around to maybe this is the best tradeoff, though not /super/ enthusiastic - if there was some way to annotate in a way that's easier for users (like a bit on the function - "transparent" or something - that lets you call the function, but is sort of nodebug-ish (skip any calls that don't have debug info, step further into other functions that have this transparent attribute on them until you reach something with debug info)) - because there's probably a lot of functions in things like the standard library that'd be nice to skip over - or have the debugger skip over them in the same way (currently I think lldb hardcodes skipping over things in the std namespace, but fails to step into user code inside those calls - like `make_unique` - you can't step into the user's ctor, it skips over th ewhole thing - admittedly there you'd still need the whole implementation call chain to be annotated with transparent so the debugger knew which bits to step into V over)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146595