smaillet-ms
commented
8 years ago This is a rather substantial work item. The current debugging architecture in VS basically looks like this: VS ---(AD7)---> MIDebugEngine ----(MI)----> GDB ---(RSP)---> PyOCD/OpenOCD
There are several components and API/protocol layers involved. The VS+MIDebugEngine is a relatively thin layer to enable VS support for Debug engines using the MI Debug protocol, such as GDB and LLDB. In turn those use another component (PyOCD or OpenOCD in our current case) as a remote debug agent talking the Remote Serial Protocol (RSP) to control the physical hardware. Thread/OS awareness exists at the RSP level and also at the MI protocol level. Thus awareness of the inner details of the scheduler's data structures must be incorporated into each RSP implementation that GDB/LLDB interacts with. There are a few options on how to get that including:
- contribute code to each of the relevant projects OpenOCD, PyOCD for now but could grow if we supported OVPSim virtual platforms (which are RSP servers as well as emulators). Over the long term this could get expensive.
- Apply an adapter component that implements RSP and sits in front of the actual RSP server. The adapter would intercept all thread related commands and handle them by calling down to the actual RSP server to retrieve whatever information it needed to provide the thread related information. This has the advantage of solving the issue for any RSP server but has an additional performance overhead of multiple command requests to the remote to get the thread data
A more ambitious alternative to the above could be to build a concord based engine that could ultimately eliminate the GDB/LLDB layer thus removing one layer of cross process communication protocol. The advantage of this approach is the existing support for expression evaluation via Roslyn and architectural support for targeting different platforms need similar kinds of functionality and therefore provide some overlap/room to leverage existing work (i.e. existing .NET Native for Windows Universal applications and LLILC )
We cannot currently see threads in GDB, and neither we can in VS2015. We should enable that to allow productive debugging.