* 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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).