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

[Augusto Noronha via Phabricator via cfe-commits]

augusto2112 added a comment.



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

> 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`?

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.

Sorry if I misunderstood your suggestion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D146595