On Mon, Oct 2, 2017, at 08:22, Kuehling, Felix wrote: > Is the "new debug trap handler" already working? It seems right now I'm > breaking the "old" debugger backend test. However, given the current > status of that debugger, I guess we can disable those tests for now? > > Can you speak on behalf of the debugger team, or should I consult someone > else on their end as well? The existing debug API was designed to interact with live wavefronts on the device. This created problems for the scheduler, which needs to be able to remove wavefronts at any time without notice. The unprivileged debugger could interfere with privileged operations (e.g. debugging in the presence of oversubscribed processes, world switch in SR-IOV). It wasn't developed beyond internal test cases and the ioctls should not have been upstreamed. The debugger was redesigned to work with offline wavefront state collected through wavefront context save (already implemented in the scheduler and controlled through hsaKmtUpdateQueue). This respects the privilege model and is robust in all scheduling scenarios. There are stil some yet-to-be-determined interfaces to control per-process debugging features. This could extend/repurpose an existing ioctl or require a new one.
