This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 
> > 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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]