Re: Multiexec MI broke MI compatibility?

[Vladimir Prus <ghost@cs.msu.su>]

Marc Khouzam wrote:
>> -----Original Message-----
>> From: gdb-owner@sourceware.org 
>> [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus
>> Sent: Tuesday, April 13, 2010 12:54 PM
>> To: gdb@sources.redhat.com
>> Subject: Re: Multiexec MI broke MI compatibility?
>>
>> Frederic Riss wrote:
>>> Hi,
>>>
>>> I tried to use the latest GDB CVS version with Eclipse Galileo DSF
>>> Debug launch, and it failed to launch a debug session. I 
>> looked at the
>>> differences with Fedora's GDB7.0 that works in the same environment
>>> and found out that the way MI reports threads totally changed. Some
>>> notifications have changed (eg. thread-group-created became
>>> thread-group-started),
>> This change was intended.
>>
>>> the way to identify thread groups has changed
>>> (thus breaking the way Eclipse did that query)...
>> If the change from numeric ids to 'iNNN' broken anything, this is
>> DSF bug. The strings were *always* documented as opaque.
> 
> I didn't actually try it myself, but the following was posted to
> a DSF-GDB bug.  Looks like a GDB problem, no?
> 
> 797,561 9-exec-run
> 797,562 =thread-group-started,id="i1",pid="24272"   <--------- GDB gies group id 'i1'
> 797,562 =thread-created,id="1",group-id="i1"
> 797,562 9^running
> 797,562 *running,thread-id="all"
> 797,562 (gdb) 
> 797,587
> =library-loaded,id="/lib/ld-linux.so.2",target-name="/lib/ld-linux.so.2",host-name="/lib/ld-\
> linux.so.2",symbols-loaded="0",thread-group="i1"
> 797,591
> =library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",\
> symbols-loaded="0",thread-group="i1"
> 797,605
> *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x080483bd",func="main",\
> args=[],file="../src/Helloworld.c",fullname="/work1/friss/workspace/Helloworld/src/Helloworld.c",lin\
> e="15"},thread-id="1",stopped-threads="all",core="0"
> 797,605 (gdb) 
> 797,748 10-list-thread-groups i1   
> 797,748 10^error,msg="invalid group id 'i1'"  <-------------- when we ask for the same is, GDB rejects it
> 797,749 (gdb)

This sounds like a bug indeed. Can you file an issue?

>>> All that changed
>>> with the introduction of Multiexec MI.
>>>
>>> This leads to some questions:
>>>  - Was that expected?
>> The change from thread-group-created to thread-group-started 
>> was intended.
>> I don't think Marc raised any concerns about that. I was no aware that
>> any released DSF version has actual support for multiexec. I 
>> am not aware of any other change from documentated behaviour.
> 
> I don't remember this change at all.  Which means nothing really, my
> memory is swiss cheese these days.
> But it does seem like a strange choice, since the previous format
> was already released.  We actually use it in DSF-GDB with GDB 7.0.
 >
> If this change needs to be done, I'm gonna have to have code like
> 	if (event.equals("thread-group-created") || event.equals("thread-group-started")
> in a couple of places.
> 
> What is the change meant to improve?

The meaning? thread-group is not actually created when this notification is emitted,
it's created/added much earlier.

>>>  - What kind of backward compatibility does the MI 
>> interface provide?
>>
>> It generally should be backward compatible within given MI 
>> version (currently 2).
> 
> Except for the above? ;-)
> 
>>>  - Is there a GUI working with the latest GDB and supporting the
>>> Multiexec features?
>> No idea.
> 
> My guess is that there isn't.  At least, there is none in eclipse.
> But it's planned, if we can find time for it.

Oh, I'm confused. If you don't support multi-exec, then why are you using thread-group-created
notification at all? It's meant for multi-exec support only.

- Volodya