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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Abeer Bagul
> Sent: Saturday, April 23, 2011 7:34 AM
> To: CDT General developers list.
> Cc: pmac@xxxxxxxxxxxxx; shaijup@xxxxxxxxxxxxx
> Subject: [cdt-dev] Handling protocol changes between gdb 6.8 and 7.1
> 
> 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="_Do
> ubleExceptionVecto\
> r",args=[],file="/build/tree/RD-2011.1_kuma/tools/swtools-MSWi
> n32-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.

With GDB 7.0, the *stopped event is much more consistent, which
is much nicer for CDT generally.  But it does cause problems
if you coded against _not_ receiving it.

I'm curious to know, is this problem specific to Xplorer or
does it happen in CDI-GDB?

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

I seem to remember that if you compile your binary with mutli-thread
support, the thread number will be 1, but if you compile it without
multi-thread support, the number will be 0.

In DSF-GDB, treat threads generically so that the id does not matter.
However, we do have a bit of specialized code to create thread id 0, 
when GDB reports no threads.  Outside that code though, everything 
is pretty much the same.

> 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. 

Actually, DSF-GDB supports GDB 6.6, 6.7, 6.8, 7.0, 7.1 and 7.2.
And soon 7.3 as it is being prepared for release by the GDB
community.

> How does DSF deal with protocol changes like these, 
> and can the same design be applied to CDI?

We instantiate different versions of the DSF services based
on the version of GDB that is used by the current debug session.
You can look at GdbDebugServicesFactory.java

I'm sure this can be done with CDI, as CDI already has different
versions of code based on the debugger type (cygwin, for example).
In case you decide to go that route though, I would suggest making
sure someone will be available to commit patches for this support,
before spending too much time on it.

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

The versioning system is what we went for.

Take care.

Marc