public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* 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).