From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14974 invoked by alias); 15 May 2014 15:25:19 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 14957 invoked by uid 89); 15 May 2014 15:25:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mexforward.lss.emc.com Received: from mailuogwhop.emc.com (HELO mexforward.lss.emc.com) (168.159.213.141) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 15 May 2014 15:25:17 +0000 Received: from hop04-l1d11-si01.isus.emc.com (hop04-l1d11-si01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s4FFPEtO021120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 May 2014 11:25:14 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd03.lss.emc.com [10.254.221.145]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor) for ; Thu, 15 May 2014 11:25:11 -0400 Received: from usendtaylorx2l.lss.emc.com (usendtaylorx2l.lss.emc.com [10.243.10.188]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id s4FFPBbO002966 for ; Thu, 15 May 2014 11:25:11 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id 7310E5C97E6; Thu, 15 May 2014 11:25:10 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id 6D3625C9743 for ; Thu, 15 May 2014 11:25:10 -0400 (EDT) From: David Taylor To: gdb-patches@sourceware.org Subject: gdb.texinfo patch Date: Thu, 15 May 2014 15:25:00 -0000 Message-ID: <10463.1400167510@usendtaylorx2l> X-EMM-MHVC: 1 X-RSA-Classifications: public X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00230.txt.bz2 In writing a new stub (to replace our old stub), I have discovered what I believe to be the rule for how GDB chooses which thread to stop during the initial connection. Knowing this sooner would have saved my some grief. Hoping to help the next person avoid that same grief, here's a patch (as a unified diff against gdb/doc/gdb.texinfo of GDB 7.7) to document it. It adds text to the discussion of the qfThreadInfo / qsThreadInfo messages. Index: gdb/doc/gdb.texinfo =================================================================== RCS file: /home/cvsroot/GDB/gdb/doc/gdb.texinfo,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 gdb.texinfo --- gdb/doc/gdb.texinfo 18 Feb 2014 15:36:03 -0000 1.1.1.2 +++ gdb/doc/gdb.texinfo 15 May 2014 15:11:23 -0000 @@ -39082,6 +39083,12 @@ Refer to @ref{thread-id syntax}, for the format of the @var{thread-id} fields. +@emph{Note: @value{GDBN} will send the qfThreadInfo query during the +initial connection with the remote target. And the very first thread ID +mentioned in the reply will be stopped by @value{GDBN} in a subsequent +message. Therefore the stub should ensure that the first thread ID in +the qfThreadInfo reply is suitable for being stopped by @value{GDBN}.} + @item qGetTLSAddr:@var{thread-id},@var{offset},@var{lm} @cindex get thread-local storage address, remote request @cindex @samp{qGetTLSAddr} packet EMC has a copyright assignment on file (though I don't think this is big enough to have an issue). I do not have commit privileges, so if it is deemed suitable for inclusion, someone else will have to do the deed. David -- David Taylor dtaylor@emc.com