DW_AT_trampoline support?

[rjra100]

We're seeing behaviour when debugging code in shared objects, where LLDB thread step-in steps over functions instead of stepping into them unless target.process.thread.step-in-avoid-nodebug is set to false. If set false, we can step into a couple of lines of disassembly of what is presumably a trampoline function, then through to the function of interest. That's a viable workaround, but it's not ideal.

I can't be certain, but this review in the llvm phabricator archive looks relevant: https://reviews.llvm.org/D147292. It seems to have been accepted. However, as far as I can see the code never actually landed into the lldb source.

[llvmbot]

@llvm/issue-subscribers-lldb

Author: None (rjra100)

We're seeing behaviour when debugging code in shared objects, where LLDB `thread step-in` steps _over_ functions instead of stepping _into_ them unless `target.process.thread.step-in-avoid-nodebug` is set to false. If set false, we can step into a couple of lines of disassembly of what is presumably a trampoline function, then through to the function of interest. That's a viable workaround, but it's not ideal.

I can't be certain, but this review in the llvm phabricator archive looks relevant: https://reviews.llvm.org/D147292. It seems to have been accepted. However, as far as I can see the code never actually landed into the lldb source.

[bulbazord]

@augusto2112 Looks like you worked on something that would fix this but never landed it. Can you take a look?

[augusto2112]

Hi @rjra100, thanks for reminding me of this, I got side-tracked with other work and didn't upstream this and the accompanying clang patch. If you're on macOS or don't mind compiling clang and lldb from the apple fork (branch stable/20230725 should have the change), you can use the feature until I land this upstream. It requires you to annotate the trampoline function with __attribute__((transparent_stepping)) though. There's some documentation in swiftlang#6597. Let me know if you have any questions!

[igorkudrin]

Hi @augusto2112, thanks for the patches! I have tried them for our downstream project and they work amazingly well. I'm looking forward to seeing them ported to the upstream.

[igorkudrin]

you can use the feature until I land this upstream.

Hi @augusto2112, do you have any updates on this? The patch is awesome and I believe other platforms besides macOS will benefit from it. When do you plan to land it on the mainline? It would be great to have it in the coming LLVM 19 release. Please let me know if you need any help with reviewing the patch or anything.

[augusto2112]

Hi @rjra100, @igorkudrin I have a patch to introduce the debug_transparent on clang (#110188), which is what gets emitted as DW_AT_trampoline on DWARF. I was asked to put up an RFC looking for community input on the feature. Could you detail how you use this so I can add it as motivation on why this change is needed?

[igorkudrin]

Hi @augusto2112, sorry for the long reply. We are mostly interested in the LLDB part of the patch because it helps to step through trampoline routines such as range extension thunks generated by a linker, or other intermediate code generated by our downstream toolchain. From our perspective, the changes in LLVM/clang are needed to test the functionality in LLDB. When the patches are accepted and landed we will propose a patch for lld to generate DW_AT_trampoline for thunks created by the linker.

[rjra100]

Sorry, missed this as well. Similarly, I'm interested in the behaviour of LLDB; in particular with shared objects built with GCC. At present, when stepping into a function in a different shared object with step-in-avoid-nodebug enabled, LLDB sees a trampoline function with no debug info and instead steps over the function. I'm hoping this change might resolve that, though not certain that it will.