SUA processes can be debugged using Visual Studio debugger. If you had tried debugging SFU/Interix processes using Visual Studio debugger, you would have noticed
1. You will not be able to launch the process using the debugger (doing so would launch posix.exe and debugger would attach to it instead of the actual posix process.)
2. Fork() Debugging
If the process that is being debugged (usually referred to as the debugee) calls fork() the debugger will not attach to the child process. The child process behavior will be unpredictable.
These limitations can be overcome by installing the ‘Visual Studio debugger Add-in’ component that is available with the Utilities and SDK for SUA package available for R2, Vista and Windows Server 2008(aka longhorn).
What is ‘Visual Studio debugger Add-in’? :
‘Visual Studio debugger Add-in’ installs a Visual Studio add-in. VS Debugger Add-in supplied for SUA enables Visual studio debugger to overcome some of the limitations with debugging posix process.
How do I debug with Visual studio debugger?
1. Install Visual studio debugger Add-in Component. Re run the setup wizard for Utilities and SDK and select Visual studio debugger Add-in in the list of components to install.
2. Verify whether the add-in has installed correctly.
Open Visual Studio IDE, navigate to Tools->Add-in Manager. In the resultant window, you should see VSAddin as one of the available Add-ins.
3. Use CC with –g option to build the application. –g option instructs the compiler to generate debug information(you will find a .pdb file after compilation).
4. Start Visual Studio IDE. Click File ->Open-> Project/Solution.
Browse to the POSIX executable that has to be debugged and open it. The solution explorer (if you don’t see it click View menu-> Solution explorer) will now display the application that you want to debug
You can also do this by typing in ‘<path to devenv.exe>’/devenv.exe /debugexe<application name>. Devenv can be found at <Location at which Visual Studio is installed>\ Common7\IDE. For example, on my machine the path is ‘/dev/fs/C/Program Files/Microsoft Visual Studio 8/Common7/IDE/devenv.exe’
5. Now, Open the source file that was used to build the debugee application. (File->Open ->File menu and browse the desired file). The source file will now be displayed in the main window of the Visual Studio IDE. You can set break points etc using the main window.
You can set/unset break points by clicking on the main window frame. Refer to Visual Studio help for more information on how to set/unset break points.
6. Now, happy debugging. The first time you do this you get a popup that reads “Debugging information for ‘posix.exe’ cannot be found or does not match. No symbols loaded. Do you want to continue debugging?”
This is an innocuous message that you can simply ignore by selecting the ‘Don’t show this dialog again’ check box. If you missed selecting this check box and simply said ‘yes’, to disable this warning, click Tools, point to Options, click Debugging, select General, and then empty the check box Warn if No symbols on Launch (Native only).
The steps 5 might be a bit tedious if the application you are debugging has many source files and you are going to debug the application a number of times. In such a case, make sure you save the solution after you have opened all the source files, added break points and book marks etc. The next time around you can just open the Visual studio solution (.sln file ) to get the same set of files opened, debug points set etc.
While debugging you would also see a window, with the title ‘PosixPID (NativePID) [EXE Path]’ that displays the posix ID (pid) of the process that you are debugging. You can also see parent child relationship in case the process forks. By default, debugger is attached to both the parent and child after fork.
1. Binaries built with GCC cannot be debugged using Visual Studio
2. This feature works only with Microsoft Visual Studio 2005 (Visual Studio versions 8.x and newer).
I have just mentioned things that are specific to debugging SUA processes. If you are new to Visual Studio debugging as such, then the help files with Visual Studio should be great starting point.