Here you can view some example screenshots, which show various situations during debugging a simple program on remote Linux host using WinGDB.
Please pay attention how the data which has been read from the remote GDB backend is presented inside native Visual Studio debug windows. It looks n' feels just like a normal Visual Studio debugger.
Click on each image to view larger version.
You can see that the dynamic library libfoo.so has been opened (look in the Modules window). The debugger has stopped on a breakpoint inside some function in that library. You can set breakpoints even before loading a library, as recent GDBs support so-called pending breakpoints and WinGDB makes use of them.
The dynamic library libfoo.so has been closed, so it has disappeared from the modules list. You can also see how the call stack window changes. Another important thing is the process input/output console, where we can see output generated by program as a result of printf call. The console aims to support full VT100 terminal command set.
Now the Disassembly window has some extended features enabled (symbolic locations and binary code view). There is also the Breakpoints window at the bottom, showing the possibility of managing breakpoints also inside assembler code. We can set breakpoint at any location which has an address. It doesn't have to be the first assembly line related to source code of high-level language.