This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: MI output during program execution
- From: Nick Roberts <nickrob at snap dot net dot nz>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 28 Mar 2006 09:54:31 +1200
- Subject: Re: RFC: MI output during program execution
- References: <17142.56731.941946.838268@farnswood.snap.net.nz> <20050808130516.GA9046@nevyn.them.org> <FDDE6A38-89E2-455B-BD32-08B6B75006D5@apple.com> <17160.63891.324530.937796@farnswood.snap.net.nz> <430B9BF8.500@apple.com> <17188.60739.749026.738477@farnswood.snap.net.nz> <17198.37622.443418.520082@farnswood.snap.net.nz> <17216.38283.618507.704220@kahikatea.snap.net.nz> <20051003131829.GA19106@nevyn.them.org>
Re getting GDB to work asynchronously (19 Sep 2005):
Me> I now have something that works for GNU/Linux (probably under limited
Me> conditions). With MI it now picks up mi_exec_async_cli_cmd_continuation to
Me> print the *stopped record, even with CLI commands like "run":
Me> > Can I go ahead and create a branch? I have a version of gdb-mi.el that
Me> > works quite well with these changes. I am (naively?) hoping that there
Me> > will be some interest after Emacs 22 is released?
>
DJ> Sorry, miscommunication. You don't need approval to create a branch;
DJ> go right ahead.
I never created a branch in the repository but kept merging changes in the
repository to my/Apple's changes.
This worked OK until:
2006-03-24 Daniel Jacobowitz <dan@codesourcery.com>
* linux-nat.c (linux_ops_saved): New.
(super_mourn_inferior, kill_inferior, threaded, linux_nat_ops)
(child_mourn_inferior, child_wait, linux_nat_create_inferior)
(linux_nat_fetch_registers, linux_nat_store_registers)
(linux_nat_child_post_startup_inferior, init_linux_nat_ops): Delete.
...
Have you any one liners that might help me understand these changes and what
I can do to get GDB to work asynchronously again (at least for Linux).
Does this patch relate to (3 Oct 2005):
DJ> I violently dislike the idea of linking gdb with pthreads. I'm
DJ> confident that we can get the benefits without that, however. I've got
DJ> this patch sitting in my queue of things to play with.
--
Nick http://www.inet.net.nz/~nickrob