Description Mathias Kunter 2011-12-22 15:16:59 EST

Build Identifier: I20110613-1736

This bug is related to Bug 222568 and Bug 307311. MIParser's translateCString function doesn't properly parse the gdb/MI backslash escaping.

The issue is that gdb doesn't escape backslashes within stream records, while it does escape them within result and out of band records. Steps to reproduce:

Compiling and debugging the following simple test program

int main()
{
	const char *s = "back\\slash";
	return 0;
}

and looking at the gdb/MI traces shows that the backslash is escaped by gdb by using 4 backslashes:

737,828 23-stack-list-locals --thread 1 --frame 0 1
737,828 23^done,locals=[{name="s",value="0x403064 \"back\\\\slash\""}]

However, compare that to the gdb/MI traces of a simple gdb echo command:

835,421 29-interpreter-exec console "echo back\\\\slash"
835,437 ~"back\\slash"
835,437 29^done

Now gdb uses 2 backslashes to escape the single backslash. However, both the

"0x403064 \"back\\\\slash\""

and the

~"back\\slash"

string are parsed by translateCStrings(). So translateCStrings() obviously must differ between those two situations in order to properly parse the gdb/MI backslash escaping.

The reason why the current implementation works is that the MIConst class itself cares about the gdb/MI backslash escaping as well. But that's a quite unclean implementation. A proper handling of the MI backslash escaping is furthermore required to fix Bug 307311.

A proposed fix for this bug is attached. It simply adds a boolean parameter to the translateCStrings() function which switches the backslash escaping on or off, depending on the current gdb record type.

Note that this fix relies on the proposed fix for Bug 307311.

Reproducible: Always