aprantl added a comment. > If it's the latter, then, yeah, some "transparent to debugger" source > attribute might be appropriate - that lowers to a bit on the DISubprogram and > instructs LLVM to, if the function definition ends up lowering to a > trampoline, mark that for the debugger so it's transparent - and if it lowers > to a trampoline but doesn't have the source attribute, you can then still > step into the function separately from stepping into the subsequent function?
Since the glue code the Swift compiler emits may call an arbitrary number of functions before calling the one function the developer is interested in, a single bit would make it quite difficult for a debugger to understand which function is the "interesting" one. The advantage of DW_AT_trampoline is that it completely eliminates any ambiguity about where to continue stepping. 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
