From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10452 invoked by alias); 13 Apr 2010 19:40:20 -0000 Received: (qmail 10441 invoked by uid 22791); 13 Apr 2010 19:40:19 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from gate.lvk.cs.msu.su (HELO mail.lvk.cs.msu.su) (158.250.17.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Apr 2010 19:40:08 +0000 Received: from mail.lvk.cs.msu.su (localhost [127.0.0.1]) by mail.lvk.cs.msu.su (Postfix) with ESMTP id D1D871073D; Tue, 13 Apr 2010 23:39:56 +0400 (MSD) X-Spam-ASN: Received: from [127.0.0.1] (h86-62-88-129.ln.rinet.ru [86.62.88.129]) by mail.lvk.cs.msu.su (Postfix) with ESMTPSA id BA6872E38; Tue, 13 Apr 2010 23:39:56 +0400 (MSD) Message-ID: <4BC4C884.8060701@cs.msu.su> Date: Tue, 13 Apr 2010 19:40:00 -0000 From: Vladimir Prus User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marc Khouzam CC: "'gdb@sources.redhat.com'" Subject: Re: Multiexec MI broke MI compatibility? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-04/txt/msg00043.txt.bz2 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