GDB/MI lawyer for Thread Creation

GDB/MI lawyer for Thread Creation

[Alain Magloire]

Bonjour

	Need a MI protocol guru for this.  When threads are created gdb is sending 

gdb -i mi 
~"[NEW Thread 1024 (LWP 8288)]\n"


Useless for MI, how about a new OOB ?

	*thread,thread-id="8288"


or a new async-notify ?

	=thread,thread-id="8288"

Only "*stopped" is currently define as a possible oob.

Re: GDB/MI lawyer for Thread Creation

[Andrew Cagney]

> Bonjour
> 
> 	Need a MI protocol guru for this.  When threads are created gdb is sending 
> 
> gdb -i mi 
> ~"[NEW Thread 1024 (LWP 8288)]\n"
> 
> 
> Useless for MI, how about a new OOB ?
> 
> 	*thread,thread-id="8288"
> 
> 
> or a new async-notify ?
> 
> 	=thread,thread-id="8288"
> 
> Only "*stopped" is currently define as a possible oob.

BTW, co/build  kseitz_interps-20020528-branch, it also generates 
breakpoint notify events.

I think that notify is correct (although it could be argued that exec is 
a legetimate class (the difference is a bit arbitrary).

Andrew

Event notification (was Re: GDB/MI lawyer for Thread Creation)

[Alain Magloire]

> 
> > Bonjour
> > 
> > 	Need a MI protocol guru for this.  When threads are created gdb is sending 
> > 
> > gdb -i mi 
> > ~"[NEW Thread 1024 (LWP 8288)]\n"
> > 
> > 
> > Useless for MI, how about a new OOB ?
> > 
> > 	*thread,thread-id="8288"
> > 
> > 
> > or a new async-notify ?
> > 
> > 	=thread,thread-id="8288"
> > 
> > Only "*stopped" is currently define as a possible oob.
> 
> BTW, co/build  kseitz_interps-20020528-branch, it also generates 
> breakpoint notify events.
> 
> I think that notify is correct (although it could be argued that exec is 
> a legetimate class (the difference is a bit arbitrary).
> 


I went digging in the old email exchanges with kseitz ....
And yes this is what I'm looking for

one nitpicking:

- the event notifications mechanism seem to be for side effects, for example
setting a breakpoint via CLI, notification is sent informing of the side effect.
Or assigning statements having side effects.

  It does not seem to address "pure" async event.  Threads creation/destruction,
and loading of shared libs are two examples that spring to mind about the need
of notification when the inferior is still running.

  It those cases, I would say that sending an OOB instead of async-notify is more
appropriate.


Questions:
Will kseitz_interps-20020528-branch be merge to the main trunk?
Any ETA ?

I'm exited about this, it brings be closer in providing a more powerfull/flexible
gui debugger.

Re: Event notification (was Re: GDB/MI lawyer for Thread Creation)

[Andrew Cagney]

> I went digging in the old email exchanges with kseitz ....
> And yes this is what I'm looking for
> 
> one nitpicking:
> 
> - the event notifications mechanism seem to be for side effects, for example
> setting a breakpoint via CLI, notification is sent informing of the side effect.
> Or assigning statements having side effects.
> 
>   It does not seem to address "pure" async event.  Threads creation/destruction,
> and loading of shared libs are two examples that spring to mind about the need
> of notification when the inferior is still running.
> 
>   It those cases, I would say that sending an OOB instead of async-notify is more
> appropriate.

Hmm, makes sense - a real rationale.  Anyone else have comments?

Want to re-word the MI doco so this is clearer?

> Questions:
> Will kseitz_interps-20020528-branch be merge to the main trunk?
> Any ETA ?

The branch contains a lot of stuff, but importantly prototypes for two 
new features:
	- interps command
	- breakpoint events
The interps feature is now implemented in the mainline.  The breakpoint 
stuff has't been done.   One missing bit of the framework needed for 
that feature - observer.[hc] - was recently added by Joel though.

> I'm exited about this, it brings be closer in providing a more powerfull/flexible
> gui debugger.

Andrew

Re: Event notification (was Re: GDB/MI lawyer for Thread Creation)

[Alain Magloire]

> 
> 
> > I went digging in the old email exchanges with kseitz ....
> > And yes this is what I'm looking for
> > 
> > one nitpicking:
> > 
> > - the event notifications mechanism seem to be for side effects, for example
> > setting a breakpoint via CLI, notification is sent informing of the side effect.
> > Or assigning statements having side effects.
> > 
> >   It does not seem to address "pure" async event.  Threads creation/destruction,
> > and loading of shared libs are two examples that spring to mind about the need
> > of notification when the inferior is still running.
> > 
> >   It those cases, I would say that sending an OOB instead of async-notify is more
> > appropriate.
> 
> Hmm, makes sense - a real rationale.  Anyone else have comments?
> 
> Want to re-word the MI doco so this is clearer?
> 

heu .... being native french speaking... mais bien sure!!!
(evil laughter here ...)

> > Questions:
> > Will kseitz_interps-20020528-branch be merge to the main trunk?
> > Any ETA ?
> 
> The branch contains a lot of stuff, but importantly prototypes for two 
> new features:
> 	- interps command
> 	- breakpoint events
> The interps feature is now implemented in the mainline.  The breakpoint 
> stuff has't been done.   One missing bit of the framework needed for 
> that feature - observer.[hc] - was recently added by Joel though.
> 

Observers ... looking trough the code ......
Was the observer pattern also intended for other notifications then stop.
Like
	observer_attach_thread_creation()
	observer_attach_shared_loaded()

etc ...

Or it is the wrong approach?

Re: Event notification (was Re: GDB/MI lawyer for Thread Creation)

[Andrew Cagney]

> heu .... being native french speaking... mais bien sure!!!
> (evil laughter here ...)

Your English can't be worse than my American.

>> > Questions:
>> > Will kseitz_interps-20020528-branch be merge to the main trunk?
>> > Any ETA ?
> 
>> 
>> The branch contains a lot of stuff, but importantly prototypes for two 
>> new features:
>> 	- interps command
>> 	- breakpoint events
>> The interps feature is now implemented in the mainline.  The breakpoint 
>> stuff has't been done.   One missing bit of the framework needed for 
>> that feature - observer.[hc] - was recently added by Joel though.
>> 
> 
> 
> Observers ... looking trough the code ......
> Was the observer pattern also intended for other notifications then stop.
> Like
> 	observer_attach_thread_creation()
> 	observer_attach_shared_loaded()
> 
> etc ...

Yes, that's the intent.  Finally a single notification mechanism.

The other bit is a script to convert gdb/doc/observer.texi into 
gdb/observer.[hc].

Andrew