This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch:MI] Observer for thread-changed
> > > Are you planning to write tests, and document the new notification?
> >
> > There certainly should be tests and documentation, and I will do write
> > some, but I don't see any for the existing notifications, namely
> > "thread-created" and "thread-exited".
>
> You probably missed those. Here's what my checkout of gdb.texinfo reads:
>
> @item =thread-created,id="@var{id}"
> @itemx =thread-exited,id="@var{id}"
> A thread either was created, or has exited. The @var{id} field
> contains the @value{GDBN} identifier of the thread.
OK. Are there any tests?
I think that event notifications should have their own node. I also think that
the manual should be restructured so that the node "GDB/MI Output Records"
comes _under_ the node "GDB/MI Command Syntax" and that the nodes in "GDB/MI
Output Records" are linked with their description in "GDB/MI Output Syntax"
> > You could say the same about user-defined functions that use the "threads"
> > command.
> No, because user-defined functions are typed by the user and passed through
> to GDB, and if those commands change thread, UI should update. On the
> contrary, if the frontend sent -thread-select, it means it wanted to set GDB
> current thread to be the same as the current thread presently shown in the
> UI, so I see no point for frontend to be notified. Can you outline a use case
> where frontend would actually like to be notified about the thing it just
> did?
In my scenario the frontend would automatically display the selected thread,
not select the thread that is displayed.
> > I don't think MI should be used as a programming language. I don't think
> > -thread-select should be used by the front end except when the user
> > explicitly requests to change threads. In fact, I would even suggest that
> > there should be no -thread-select and that all MI commands should be
> > reflective
> What is "reflective"?
Maybe it's not the right word. Perhaps I mean introspective, i.e., just
reports the state like -break-list or -environment-pwd and doesn't change it
like -thread-select or -stack-select-frame, for example.
> > With a complete set of notifications, the usual CLI commands could be used
> > to change state and the front end could just parse the MI output.
> Could be used where? If in GDB console, then sure, but that does not require
> that -thread-select output notification.
I mean the front end could just use CLI commands to change the state provided
there were MI notifications that would report that change.
> > But the first patch was wrong for other reasons, as Pedro pointed out.
> IIUC, the primary objection was that we'd emit notification even if
> gdb_thread_select caught an exception. Can we protect against this by
> checking that inferior_ptid actually changed?
Pedro says he has a patch that splits the notion of user/frontend selected
thread and frame, from the internally selected thread and frame. Let's wait
to see how that fits in.
--
Nick http://www.inet.net.nz/~nickrob