This is the mail archive of the gdb-patches@sourceware.org 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]

Re: RFC: MI output during program execution


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":

Great!

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

  http://sources.redhat.com/gdb/current/onlinedocs/gdbint_15.html#SEC133

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

-- 
Daniel Jacobowitz
CodeSourcery, LLC


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