This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Merge of nickrob-async-20060513 to mainline?
- From: Daniel Jacobowitz <drow at false dot org>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 26 Sep 2006 08:37:58 -0400
- Subject: Re: Merge of nickrob-async-20060513 to mainline?
- References: <17652.63229.637451.185345@kahikatea.snap.net.nz> <20060830023335.GA6377@nevyn.them.org> <17653.930.196634.143646@kahikatea.snap.net.nz> <20060830040113.GA8257@nevyn.them.org> <17654.994.815362.897653@kahikatea.snap.net.nz> <20060830214257.GA5397@nevyn.them.org> <17688.59135.24869.397517@kahikatea.snap.net.nz>
On Tue, Sep 26, 2006 at 08:38:23PM +1200, Nick Roberts wrote:
> Below is a (pseudo) diff fragment that should (hopefully) give the general
> idea. Do you mean something along these lines? If yes, I'll try to get it
> to work more generally.
Yes, this should work, though it seems cumbersome. When you've got
a single thread, you don't need to pass actual data around an fd,
just a marker "yes i'm ready now".
Moving the call to waitpid out of linux-nat.c, and to a target
independent file, is a mistake - presumably that's just how you got it
to work quickly? That's related to why it doesn't work for threads.
The vital line is "options ^= __WCLONE" in the loop in linux_nat_wait.
Without __WCLONE, you'll never see a wait status from a thread; with
it you'll never see a wait status from the main program.
Ideally you'd be able to reuse the signal handler logic (see the calls
to sigprocmask and sigsuspend) and thus not have a millisecond latency
and excessive spinning. That's actually a pretty important feature,
because context switching to gdb every millisecond or so is going to
really hurt performance of the debuggee.
--
Daniel Jacobowitz
CodeSourcery