This is the mail archive of the gdb@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: Merge of nickrob-async-20060513 to mainline?


On Thu, Aug 31, 2006 at 09:32:18AM +1200, Nick Roberts wrote:
>  > Just generate the diff between your mergepoint and branch, and then
>  > pipe it to diffstat, assuming you've got it installed.
> 
> Doing:
> 
> cvs diff -r nickrob-async-20060828-mergepoint gdb | diffstat
> 
> from the src directory gives the output below.

Not too bad.

>  > Well, I meant from an internals perspective - like, a patch just
>  > summarizing the interface changes, if the whole patch is too big to
>  > post at once.
> 
> Instead of GDB waiting for the enferior to stop directly, it creates a signal
> thread to do that.  This means that the main thread can continue to process the
> event loop.  When the inferior does stop, the signal thread writes to a file
> which GDB detects through handle_file_event in the event loop. It then calls
> inferior_event_handler.

OK, this is easily mimicable without threads, at least on GNU/Linux.

On Cygwin/Windows I imagine we'd want to use threads, but the tradeoffs
there are somewhat different :-)

>  > > Also it still uses pthreads.  You said previously that it should be done
>  > > in one process and, following a remark from Jim Ingham, that ptrace is
>  > > non-blocking.  AFAICS the problem is that wait *is* blocking and I can't
>  > > see of a way to deal with that without using another thread.
>  > 
>  > Ah, but wait is non-blocking.  You have to (A) use WNOHANG, and (B) be
>  > careful to handle asynchronous SIGCHLD events.  It's not especially
>  > difficult, I don't think, but the async event loop in gdb has always
>  > confused me; we'll have to figure out how to gather up sigchld/wait
>  > events.
> 
> The manpage just says:
> 
>        WNOHANG
>               return immediately if no child has exited.
> 
> but what value does it return with?  Does GDB ignore SIGCHLD events so it
> can detect state changes through wait?

If that's all it says I recommend a better man page :-)

       waitpid(): on success, returns the process ID of the child whose
       state has changed; on error, -1 is returned; if WNOHANG was
       specified and no child(ren) specified by pid has yet changed
       state, then 0 is returned.

Different ports of GDB treat SIGCHLD differently.  linux-nat.c, for
instance, blocks it so that it can use sigsuspend.  Instead, we would
have to register handlers for sigchld events somehow (probably using
the same infrastructure used for SIGINT to quit operations).

I can work on this, though not right away.

-- 
Daniel Jacobowitz
CodeSourcery


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