Re: problem with new vforkdone stop reply in 7.10

[Pedro Alves <palves@redhat.com>]

On 09/15/2015 03:51 PM, Pedro Alves wrote:
> 
> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
> index 395f0d4..3ac8c43 100644
> --- a/gdb/doc/gdb.texinfo
> +++ b/gdb/doc/gdb.texinfo
> @@ -35498,10 +35498,11 @@ indicating support.
>  
>  @cindex vforkdone events, remote reply
>  @item vforkdone
> -The packet indicates that a child process created by a vfork
> -has either called @code{exec} or terminated, so that the
> -address spaces of the parent and child process are no longer
> -shared. The @var{r} part is ignored.  This packet is only
> +The packet indicates that a child process created by a vfork has
> +either called @code{exec} or terminated, so that the address spaces of
> +the parent and child process are no longer shared. The @var{r} part is
> +the thread ID of the parent process.  Refer to @ref{thread-id syntax}
> +for the format of the @var{thread-id} field.  This packet is only
>  applicable to targets that support vforkdone events.
>  

Actually, I don't know what I was thinking when I wrote that docs
patch.  What I really think we should be doing is report the parent
thread id with the usual "thread" magic register:

  Sending packet: $vCont;c:p7260.7260#1e...Packet received: OK
-   Notification received: Stop:T05vforkdone:;
+   Notification received: Stop:T05vforkdone:;06:40d7ffffff7f0000;07:30d7ffffff7f0000;10:e4c9eb1536000000;thread:p7260.7260;core:3;
                                                                                                          ^^^^^^^^^^^^^^^^^

This is already how the parent is reported in the vfork/fork events,
and is actually what the code fix did.  But somehow I blindly copied
that "{r} part is the thread ID" doc bit from the fork event docu
without realizing I was documenting it wrong.  My bad...

I'll fix that up.

Thanks,
Pedro Alves