[cdt-dev] Handling protocol changes between gdb 6.8 and 7.1

[Abeer Bagul <abeer4eclipse@xxxxxxxxx>]

Hi All,

We are upgrading gdb from version 6.8 to 7.1 in our Xplorer IDE. Currently the product is using CDI framework, while the DSF framework is being integrated. However, there are quite a few changes in protocol between the two versions.
These changes are related to the output by gdb in -mi2 mode. 

An example:
When the launch issues a target-select command:
-target-select remote localhost:20000

In gdb 6.8, the output used to be:
~"Current language:  auto; currently asm\n"
328^connected,thread-id="0",frame={addr="0x6000025f",func="_DoubleExceptionVecto\
r",args=[],file="/build/tree/RD-2011.1_kuma/tools/swtools-MSWin32-x86/xtensa-elf/src/xtos/double-vec\
tor.S",line="69"}

This output has header ^connected, which means the output is the response of the target select command. This output is synchronously attached to the target remote command, and the launch proceeds sequentially to issue later commands such as initializing registers, stack info depth, stack list frames etc. All this happens sequentially in the same launch delegate thread which issued the target select command.

In gdb 7.1, the output of target select is now:
300-target-select remote localhost:20000 =thread-group-created,id="1001"
=thread-created,id="1",group-id="1001"
*stopped,frame={addr="0x60000087",func="_DebugExceptionVector",args=[],file="/bu\
ild/tree/cw_eng1_kuma/tools/swtools-MSWin32-x86/xtensa-elf/src/xtos/debug-vector.S",line="58"},threa\
d-id="1",stopped-threads="all"
300^connected

This is a change in the output, from "response to command" to "event message". The line starting with *stopped creates an event object in Xplorer, and the event is fired in a different event thread. This creates a race condition between the launch delegate thread and the event thread, breaking the initialization sequence.

Another issue is that earlier, thread-id used to be 0, but now it is 1, though our RTOS does not support multi threading. 

How to deal with these protocol changes on the IDE side, can we use any specific design pattern, or is some design possible so that version specific protocol changes are contained in a single layer in the CDI integration part of the IDE?

Currently DSF supports three versions of gdb, i.e. 6.8, 7.0 and 7.1. How does DSF deal with protocol changes like these, and can the same design be applied to CDI?

I know it is a very generic question, but any pointers would be greatly appreciated.

Thanks
Abeer 
Tensilica India