Bug 356085

Description Stefan Bylund 2011-08-29 10:26:06 EDT

Build Identifier: Eclipse 3.7.0 (Build id: I20110613-1736), CDT 8.0.0 (Build id: 201106081058)

Problem Description
-------------------

I will start with some background information. Starting from CDT 7, a Windows program that is debugged with CDT and GDB will not get a native Windows console but will instead be integrated with the Eclipse console. Due to this change, CDT 7 and 8 does not support source code debugging with GDB of Windows programs that prints non-newline-terminated strings on stdout. This bug appears both in CDI's and DSF's GDB support but this bug report focuses on CDI (see bug 356082 for the corresponding DSF bug report and fix).

This is not a problem on operating systems that support pseudo terminals (like Linux but not Windows). On Linux, CDT redirects the debugged program's output to a different pseudo terminal (TTY). That lets CDT unambiguously differentiate between GDB's output and the debugged program's output. Windows doesn't have TTYs, so the output from GDB and the debugged program can be interleaved if the debugged program prints non-newline-terminated strings on stdout at the same time as an event occurs in GDB (e.g. the end of a single-step over the offending printf() line in the debugged program). The problem is that the current GDB MI parser fails to recognize this fact and consequently does not react to the MI output that signals the end of the single-step operation, which makes the debug session appear as it has hanged.

Solution
--------

Since Windows doesn't have pseudo terminals, the GDB MI parser can only make a best effort of differentiating between the output from GDB and the debugged program. Currently, this differentiating is much too weak, as is demonstrated by the the example above.

I have only been able to get interleaved output from GDB and its debugged program when I single-step over non-newline-terminated output on stdout from the debugged program. In those cases, the output from the debugged program always precedes the output from GDB, like this:

<debugged-program-output><gdb-mi-output>\n

So, one straighforward way to make the GDB MI parser much more robust on Windows is to let its main loop (which reads each line of output from GDB and parses it) analyze the line of output from GDB and try to split it up in one debugged program part and in one GDB part (if they occur on the same line) and then send those two separate lines of output to the GDB MI parsing method. The code for splitting up the output from GDB uses a regular expression of the GDB MI output grammar.

A patch, relative to CDT 8.0.0, for the GDB MI parser in CDI is provided. When making the fixes for both CDI and DSF, I noticed that the GBD MI parser in DSF, which was based on the GDB MI parser in CDI, contains improved parsing of the 'token' part of the GDB MI output. I have added those improvements back to the GDB MI parser in CDI since they are needed to make this fix robust in the CDI case as well.

The classes org.eclipse.cdt.debug.mi.core.RxThread and org.eclipse.cdt.debug.mi.core.output.MIParser in the org.eclipse.cdt.debug.mi.core plugin have been updated.


Reproducible: Always

Steps to Reproduce:
1. Make sure that you have a MinGW or Cygwin GCC/GDB installed.
2. Create an empty C project for executables and choose the toolchain MinGW GCC or Cygwin GCC.
3. Add the attached file test.c to the project and build it.
4. Create a "C/C++ Application" debug launch configuration and choose "Standard Create Process Launcher" as launcher.
5. Launch the debugger; you should now be in the main() function in test.c.
6. Try to step over the printf() and fflush() lines; one of them will fail, typically the fflush() line!
7. The debug session is now hanged...