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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits