* Multiexec MI broke MI compatibility? @ 2010-04-12 13:30 Frederic Riss 2010-04-13 16:54 ` Vladimir Prus 0 siblings, 1 reply; 10+ messages in thread From: Frederic Riss @ 2010-04-12 13:30 UTC (permalink / raw) To: gdb 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), the way to identify thread groups has changed (thus breaking the way Eclipse did that query)... All that changed with the introduction of Multiexec MI. This leads to some questions: - Was that expected? - What kind of backward compatibility does the MI interface provide? - Is there a GUI working with the latest GDB and supporting the Multiexec features? Thanks! Fred ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Multiexec MI broke MI compatibility? 2010-04-12 13:30 Multiexec MI broke MI compatibility? Frederic Riss @ 2010-04-13 16:54 ` Vladimir Prus 2010-04-13 17:32 ` Marc Khouzam 0 siblings, 1 reply; 10+ messages in thread From: Vladimir Prus @ 2010-04-13 16:54 UTC (permalink / raw) To: gdb 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. > 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. > - What kind of backward compatibility does the MI interface provide? It generally should be backward compatible within given MI version (currently 2). > - Is there a GUI working with the latest GDB and supporting the > Multiexec features? No idea. - Volodya ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-04-13 16:54 ` Vladimir Prus @ 2010-04-13 17:32 ` Marc Khouzam 2010-04-13 19:40 ` Vladimir Prus 0 siblings, 1 reply; 10+ messages in thread From: Marc Khouzam @ 2010-04-13 17:32 UTC (permalink / raw) To: 'Vladimir Prus', 'gdb@sources.redhat.com' > -----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) > > 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? > > - 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. Marc ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Multiexec MI broke MI compatibility? 2010-04-13 17:32 ` Marc Khouzam @ 2010-04-13 19:40 ` Vladimir Prus 2010-04-13 20:33 ` Marc Khouzam 0 siblings, 1 reply; 10+ messages in thread From: Vladimir Prus @ 2010-04-13 19:40 UTC (permalink / raw) To: Marc Khouzam; +Cc: 'gdb@sources.redhat.com' 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-04-13 19:40 ` Vladimir Prus @ 2010-04-13 20:33 ` Marc Khouzam 2010-04-14 8:12 ` Frederic Riss 0 siblings, 1 reply; 10+ messages in thread From: Marc Khouzam @ 2010-04-13 20:33 UTC (permalink / raw) To: Vladimir Prus; +Cc: 'gdb@sources.redhat.com' >> 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? I'm hoping Frederic can do that since he knows the proper details. > > 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. Well, not really the meaning, which I now understand, but more: what is the value in making this change? > >>> - 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. I don't think I could have been more obscure if I tried. Sorry. DSF-GDB support multi-process (single address space targets) but not multi-exec (e.g., Linux target). And we use -thread-group-created et al., whenever we use GDB 7.0 because we have prepared for the more general case of multi-exec, even on Linux, even if we currently don't fully support it. I hope that is a little less cryptic. Marc ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Multiexec MI broke MI compatibility? 2010-04-13 20:33 ` Marc Khouzam @ 2010-04-14 8:12 ` Frederic Riss 2010-06-04 13:46 ` Marc Khouzam 0 siblings, 1 reply; 10+ messages in thread From: Frederic Riss @ 2010-04-14 8:12 UTC (permalink / raw) To: Marc Khouzam; +Cc: Vladimir Prus, gdb Hi! On 13 April 2010 22:33, Marc Khouzam <marc.khouzam@ericsson.com> wrote: >>> 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? > > I'm hoping Frederic can do that since he knows the proper details. Done here: http://sourceware.org/bugzilla/show_bug.cgi?id=11499 This leaves the question of whether the thread-group-created notification name change was appropriate (From a backward compatibility POV, not from a pure 'it makes sense' angle). Thanks! Fred ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-04-14 8:12 ` Frederic Riss @ 2010-06-04 13:46 ` Marc Khouzam 2010-06-05 5:16 ` Vladimir Prus 0 siblings, 1 reply; 10+ messages in thread From: Marc Khouzam @ 2010-06-04 13:46 UTC (permalink / raw) To: 'gdb@sources.redhat.com' > -----Original Message----- > From: Frederic Riss [mailto:frederic.riss@gmail.com] > Sent: Wednesday, April 14, 2010 4:12 AM > To: Marc Khouzam > Cc: Vladimir Prus; gdb@sources.redhat.com > Subject: Re: Multiexec MI broke MI compatibility? > > Hi! > > On 13 April 2010 22:33, Marc Khouzam > <marc.khouzam@ericsson.com> wrote: > >>> 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? > > > > I'm hoping Frederic can do that since he knows the proper details. > > Done here: > http://sourceware.org/bugzilla/show_bug.cgi?id=11499 As there are discussions for an earlier release of 7.2, I wanted to mention this regression. I think this is something that should be fixed before 7.2. > This leaves the question of whether the thread-group-created > notification name change was appropriate (From a backward > compatibility POV, not from a pure 'it makes sense' angle). As for this, is the plan to keep the change or to revert? Thanks Marc ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-06-04 13:46 ` Marc Khouzam @ 2010-06-05 5:16 ` Vladimir Prus 2010-06-08 0:36 ` Marc Khouzam 0 siblings, 1 reply; 10+ messages in thread From: Vladimir Prus @ 2010-06-05 5:16 UTC (permalink / raw) To: gdb Marc Khouzam wrote: > > >> -----Original Message----- >> From: Frederic Riss [mailto:frederic.riss@gmail.com] >> Sent: Wednesday, April 14, 2010 4:12 AM >> To: Marc Khouzam >> Cc: Vladimir Prus; gdb@sources.redhat.com >> Subject: Re: Multiexec MI broke MI compatibility? >> >> Hi! >> >> On 13 April 2010 22:33, Marc Khouzam >> <marc.khouzam@ericsson.com> wrote: >> >>> 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? >> > >> > I'm hoping Frederic can do that since he knows the proper details. >> >> Done here: >> http://sourceware.org/bugzilla/show_bug.cgi?id=11499 > > As there are discussions for an earlier release of 7.2, > I wanted to mention this regression. > I think this is something that should be fixed before 7.2. Yes, working on that now. > >> This leaves the question of whether the thread-group-created >> notification name change was appropriate (From a backward >> compatibility POV, not from a pure 'it makes sense' angle). > > As for this, is the plan to keep the change or to revert? The plan is to keep the change, sorry. - Volodya ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-06-05 5:16 ` Vladimir Prus @ 2010-06-08 0:36 ` Marc Khouzam 2010-06-21 18:32 ` Marc Khouzam 0 siblings, 1 reply; 10+ messages in thread From: Marc Khouzam @ 2010-06-08 0:36 UTC (permalink / raw) To: 'Vladimir Prus', gdb > -----Original Message----- > From: gdb-owner@sourceware.org > [mailto:gdb-owner@sourceware.org] On Behalf Of Vladimir Prus > Sent: Saturday, June 05, 2010 1:16 AM > To: gdb@sources.redhat.com > Subject: RE: Multiexec MI broke MI compatibility? > > Marc Khouzam wrote: > > > > > > >> -----Original Message----- > >> From: Frederic Riss [mailto:frederic.riss@gmail.com] > >> Sent: Wednesday, April 14, 2010 4:12 AM > >> To: Marc Khouzam > >> Cc: Vladimir Prus; gdb@sources.redhat.com > >> Subject: Re: Multiexec MI broke MI compatibility? > >> > >> Hi! > >> > >> On 13 April 2010 22:33, Marc Khouzam > >> <marc.khouzam@ericsson.com> wrote: > >> >>> 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? > >> > > >> > I'm hoping Frederic can do that since he knows the > proper details. > >> > >> Done here: > >> http://sourceware.org/bugzilla/show_bug.cgi?id=11499 > > > > As there are discussions for an earlier release of 7.2, > > I wanted to mention this regression. > > I think this is something that should be fixed before 7.2. > > Yes, working on that now. Thanks, I saw that it is now fixed. I'll give it a spin with DSF-GDB next week. > >> This leaves the question of whether the thread-group-created > >> notification name change was appropriate (From a backward > >> compatibility POV, not from a pure 'it makes sense' angle). > > > > As for this, is the plan to keep the change or to revert? > > The plan is to keep the change, sorry. Ok, I'll put a check for both formats in DSF-GDB. Of course, any frontend that decides to makes use of the thread-group-created/started will need to be careful if they want to also support GDB 7.0 and GDB 7.1. Marc ^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Multiexec MI broke MI compatibility? 2010-06-08 0:36 ` Marc Khouzam @ 2010-06-21 18:32 ` Marc Khouzam 0 siblings, 0 replies; 10+ messages in thread From: Marc Khouzam @ 2010-06-21 18:32 UTC (permalink / raw) To: 'Vladimir Prus', 'gdb@sources.redhat.com' > > >> Done here: > > >> http://sourceware.org/bugzilla/show_bug.cgi?id=11499 > > > > > > As there are discussions for an earlier release of 7.2, > > > I wanted to mention this regression. > > > I think this is something that should be fixed before 7.2. > > > > Yes, working on that now. > > Thanks, I saw that it is now fixed. > I'll give it a spin with DSF-GDB next week. FYI, I've tried the changes addressing this bug with DSF-GDB and things work well. One thing I noticed is that (besides the change of name) =thread-group-created,id="12725" is now =thread-group-started,id="i1",pid="12791" The pid is now given. I think this is a great thing and I'll be making use of it. Thanks! Marc ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2010-06-21 18:32 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-12 13:30 Multiexec MI broke MI compatibility? Frederic Riss 2010-04-13 16:54 ` Vladimir Prus 2010-04-13 17:32 ` Marc Khouzam 2010-04-13 19:40 ` Vladimir Prus 2010-04-13 20:33 ` Marc Khouzam 2010-04-14 8:12 ` Frederic Riss 2010-06-04 13:46 ` Marc Khouzam 2010-06-05 5:16 ` Vladimir Prus 2010-06-08 0:36 ` Marc Khouzam 2010-06-21 18:32 ` Marc Khouzam
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox