This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Event notification (was Re: GDB/MI lawyer for Thread Creation)
- From: "Alain Magloire" <alain at qnx dot com>
- To: gdb at sources dot redhat dot com
- Date: Wed, 7 May 2003 11:19:45 -0400 (EDT)
- Subject: 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.