This is the mail archive of the
mailing list for the GDB project.
Re: RFC: MI output during program execution
- From: Daniel Jacobowitz <drow at false dot org>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 19 Sep 2005 09:17:43 -0400
- Subject: Re: RFC: MI output during program execution
- References: <firstname.lastname@example.org> <20050808130516.GA9046@nevyn.them.org> <FDDE6A38-89E2-455B-BD32-08B6B75006D5@apple.com> <email@example.com> <430B9BF8.firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On Mon, Sep 19, 2005 at 10:29:10PM +1200, Nick Roberts wrote:
Content-Description: message body text
> > I've started a merge on current CVS (for some reason gdb-413 seemed to
> > include everything except the GDB source). Getting MI output during
> > program execution seems to be closely related to making GDB asynchronous.
> > I couldn't attempt such a task on my own but, using the Apple code as a
> > prototype, it doesn't look too difficult. When I have something working
> > perhaps I could put it on a branch.
> I now have something that works for GNU/Linux (probably under limited
> conditions). With MI it now picks up mi_exec_async_cli_cmd_continuation to
> print the *stopped record, even with CLI commands like "run":
> I attach the new files and a set of diffs against HEAD from about 20:00 NZST
> (+12 GMT) Sept 19 2005, for anyone who might like to test the functionality.
> If I am given approval to commit these changes to a branch then I will create
> ChangeLog entries (attributed to Apple).
> I presume there is more freedom to committing on a non-release branch. What
> are the rules?
The rules for a branch are, generally, up to the branch owner. The
only one I'll insist on is that copyright assignments be handled in the
same way as for HEAD, which is not a problem here. See:
(which are mostly guidelines rather than rules). So, you can create a
branch if you'd like.
I took a quick look at the changes, but couldn't make heads or tails
out of what was going on. Also, I think the diff is corrupted; the
changes to linux-nat.c cut off in a very strange place in child_wait().
Maybe when it's been cleaned up a little we can look for a way to do
this that doesn't involve pthreads.