[RFA] Add comments to linux-nat.c
Eli Zaretskii
eliz@gnu.org
Sat Jun 14 19:51:00 GMT 2008
> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sat, 14 Jun 2008 18:29:05 +0400
>
>
> With the introduction of async mode, linux-nat.c became even more complex that it
> was, and it became apparent that some high-level comments are needed. So, I've grabbed
> Pedro and Dan on IRC and extracted the knowledge from their heads into a text file.
> Here's the result. OK?
Thanks. I don't know anything about the subject matter, but I spotted
a few typos in the text:
> +threads. (2.4 has the __WALL flag). So, it we use blocking waitpid, we might
^^
"if"
> +sigsuspend. First, we use non-blocking waitpid to get if there's event
"to get if there's event" is not quite right, you probably wanted to
say "to find out if there's event".
> +in main debugged process and in cloned processes. child processes. As soon
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Something's wrong here.
> +The main design point is that every time GDB is outside linux-nat.c, we have a
> +SIGCLD handler installed that is called when something happens to the target
^^^^^^
SIGCLD or SIGCHLD?
> +Those waitpid calls, while blocking, are guarantied to always always have
^^^^^^^^^^^^^
"always" twice.
> +of the pipe amoung the sources. When event loop starts to process the event
^^^^^^
"among"
> +us. Technically, it would be possible to add new events to the local queue but
> +it's about the same amount of work than blocking SIGCHLD.
^^^^^^^^^^^^^^^^^^^^^
"as blocking SIGCHLD"
> +enter/leave linux-nat.c is somewhat ugly. Unfortunately, GDB event loop is
> +home-grown is incapable to wait on any queue.
Something's wrong in "is home-grown is incapable".
> +tkill'd. But we never let the SIGSTOP deliver; we always intercept and cancel
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"never let SIGSTOP be delivered".
More information about the Gdb-patches
mailing list