t-tye added a comment. In D68578#1697898 <https://reviews.llvm.org/D68578#1697898>, @tra wrote:
> In D68578#1697851 <https://reviews.llvm.org/D68578#1697851>, @yaxunl wrote: > > > In D68578#1697822 <https://reviews.llvm.org/D68578#1697822>, @tra wrote: > > > > > Could you elaborate on how exactly current implementation does not work? > > > > > > I would expect the kernel and the stub to be two distinct entities, as > > > far as debugger is concerned. It does have enough information to track > > > each independently (different address, .stub suffix, perhaps knowledge > > > whether it's device or host code). Without the details, it looks to me > > > that this is something that can and should be dealt with in the debugger. > > > I've asked the same question in D63335 <https://reviews.llvm.org/D63335> > > > but I don't think I've got a good answer. > > > > > > HIP debugger is a branch of gdb and the changes to support HIP will be > > upstreamed. When users set break point on a kernel, they intend to set a > > break point on the real kernel, not the device stub function. The device > > stub function is only a compiler generated helper function to help launch > > the kernel. Therefore it should have a different name so that it does not > > interfere with the symbol resolution of the real kernel. > > > I would agree that having distinct names for the device-side kernel and it's > host-side stub would probably make things easier for debugger. > However, debugger does have access to mangled names and does see the '.stub' > suffix in the mangled name. I don't understand why it can't be considered to > disambiguate between the kernel and the stub? > I'm clearly missing something here. Is there a chance to get someone from > the debugger team to chime in on this review directly? > > Also, I would not agree that `they intend to set a break point on the real > kernel` is the only scenario. E.g. quite often when I debug CUDA stuff, I do > only care about host-side things and I do want to set breakpoint on the stub, > so I can check kernel call parameters as they are passed to the kernel. It > would be great if there were a way to explicitly tell debugger whether we > want host-side stub or the kernel without having user to know how particular > compiler transforms the name. For the user both entities have the same name, > but distinct location and there should be a way to express that in the > debugger. From a source language point of view, the device function comprises the code that is launched as a grid. We need this fact to be present in the symbols used. Only the device function should have a symbol name matching the mangled name of the device function. It the device function has both a host and device implementation then both can have the source language function name for the symbol since both actually implement the device function. If the user asks to set a breakpoint in the device function then the debugger would set in both implementations so the user is notified when the source program executes the device function, regardless of which implementation is invoked. This is similar to the debugger setting a breakpoint in a function that is inlined into multiple places: the debugger sets breeakpoints in all the inlined places so the user can tstill think of the program debugging in terms of the source language semantics. In contrast, the stub is effectively part of the implementation of actually launching the device function. It should have a distinct name. The debugger can still be used to set a breakpoint in it, or to step into it. But that should be done in terms of the stub name. If the debugger wants to support source language specific intelligence it can provide a helper library that understands the stub names. This helper library (similar to the thread helper library) can be used by the debugger to present a cleaner language view to the user. In fact OpenMP has also done this and provides a helper library called OMPD that can be used by tools such as a debugger to hide OpenMP trampoline functions etc. I am a little unclear what this patch is doing as it is mentioned that the mangled name has a _stub in it. My understanding is that the intention was to create a distinct unmangled name for the stub, and then mangle it so that the resulting symbol was a legal mangled name. It sounded like this was the preferred approach, and makes sense to me based on my current understanding. Am I understanding this correctly? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68578/new/ https://reviews.llvm.org/D68578 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
