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: 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, 3 Oct 2005 16:31:08 -0400
- 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> <17217.34460.753468.405145@kahikatea.snap.net.nz>
On Tue, Oct 04, 2005 at 08:29:32AM +1300, Nick Roberts wrote:
> Daniel Jacobowitz writes:
> > Sorry, miscommunication. You don't need approval to create a branch;
> > go right ahead.
>
> OK. Thanks.
>
> > I violently dislike the idea of linking gdb with pthreads. I'm
> > confident that we can get the benefits without that, however. I've got
> > this patch sitting in my queue of things to play with.
>
> I know this will sound stupid but what is the alternative? Using fork?
Doing it "asynchronously" through the GDB event loop, which is I
believe the same way we handle remote async targets. All in one
process.
This is a little more complicated to design, however, it's got less
complexity at runtime. I've spent enough of my life using GDB on
systems where pthreads didn't work that I don't want to make GDB
dependent on them.
--
Daniel Jacobowitz
CodeSourcery, LLC