Message ID | 10463.1400167510@usendtaylorx2l |
---|---|
State | New, archived |
Headers |
Return-Path: <x14314964@homiemail-mx22.g.dreamhost.com> X-Original-To: siddhesh@wilcox.dreamhost.com Delivered-To: siddhesh@wilcox.dreamhost.com Received: from homiemail-mx22.g.dreamhost.com (mx2.sub5.homie.mail.dreamhost.com [208.113.200.128]) by wilcox.dreamhost.com (Postfix) with ESMTP id 338E436006F for <siddhesh@wilcox.dreamhost.com>; Thu, 15 May 2014 08:25:23 -0700 (PDT) Received: by homiemail-mx22.g.dreamhost.com (Postfix, from userid 14314964) id D1CF85949C2F; Thu, 15 May 2014 08:25:22 -0700 (PDT) X-Original-To: gdb@patchwork.siddhesh.in Delivered-To: x14314964@homiemail-mx22.g.dreamhost.com Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by homiemail-mx22.g.dreamhost.com (Postfix) with ESMTPS id CEBF658EED12 for <gdb@patchwork.siddhesh.in>; Thu, 15 May 2014 08:25:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id; q=dns; s= default; b=kNOrB33modbl3EhWn1RTfFLISegdni7T2V9AX2rRxiodfWF1ot9Ki BvQB0urCc9MoPO9TXSCqG86rpRfTgt22IUzb142BhoJS+fRiFg1HMIA1uHzysMIv c8IgQOAgBjl+12c69Q0sIe3hLX5cWSqWrxWrBRyAT5rmm2CE/U5fvU= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:from:to:subject:date:message-id; s=default; bh=eb3PPhYDYir5PPC3AHPUufrzILs=; b=qi4Z4cmsmENE3zDrNSfNEP4xqlAL 1r76FRCEduFgCT/Eb+ow++n4XMvoveQqVGtuH2vHpsVhgmjlxZossxneN9zZCnud PAlsl5jgYZghLUaob7KOkctyIp1HsHVK2OqMxVxJKBRzyQpPSUihF8i4pFvD0t/z NbcEtDwm4cH8XZ8= 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: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-gdb=patchwork.siddhesh.in@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@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 <gdb-patches@sourceware.org>; 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 <gdb-patches@sourceware.org>; 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 <gdb-patches@sourceware.org>; 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 <gdb-patches@sourceware.org>; Thu, 15 May 2014 11:25:10 -0400 (EDT) From: David Taylor <dtaylor@emc.com> To: gdb-patches@sourceware.org Subject: gdb.texinfo patch Date: Thu, 15 May 2014 11:25:10 -0400 Message-ID: <10463.1400167510@usendtaylorx2l> X-EMM-MHVC: 1 X-RSA-Classifications: public X-IsSubscribed: yes X-DH-Original-To: gdb@patchwork.siddhesh.in |
Commit Message
David Taylor
May 15, 2014, 3:25 p.m. UTC
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. 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
Comments
On 05/15/2014 12:25 PM, David Taylor wrote: > 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 > > Does GDB always want to stop the thread, even when "may-interrupt" is set to "off"?
Luis Machado <lgustavo@codesourcery.com> wrote: > On 05/15/2014 12:25 PM, David Taylor wrote: > > 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. [...] > Does GDB always want to stop the thread, even when "may-interrupt" is=20 > set to "off"? I wasn't aware of that variable, so I don't know. It will require some investigation. Certainly with non-stop mode turned on and may-interrupt at the default value, it stops it.
On 05/15/2014 12:48 PM, David Taylor wrote: > Luis Machado <lgustavo@codesourcery.com> wrote: > >> On 05/15/2014 12:25 PM, David Taylor wrote: >>> 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. > > [...] > >> Does GDB always want to stop the thread, even when "may-interrupt" is=20 >> set to "off"? > > I wasn't aware of that variable, so I don't know. It will require some > investigation. Certainly with non-stop mode turned on and may-interrupt > at the default value, it stops it. > Yeah. Unfortunately it is another one of those obscure settings. :-) Given we have this option, it may be worth mentioning it in the piece you are patching, just for the sake of completeness. Otherwise folks may think GDB will always stop the threads when connecting. It will stop most of the time anyway, since it is the default after all. Luis
> From: David Taylor <dtaylor@emc.com> > Date: Thu, 15 May 2014 11:25:10 -0400 > > 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. Thanks. > +@emph{Note: @value{GDBN} will send the qfThreadInfo query during the ^^^^^^^^^^^^ The packet name should be in @code. > +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 Better make the second sentence part of the first (as in "..., and the very first thread ..."). > +the qfThreadInfo reply is suitable for being stopped by @value{GDBN}.} ^^^^^^^^^^^^ @code Otherwise, fine with me, assuming the contents is correct (I don't know enough to say).
Here's the revised patch: *** gdb.texinfo.~1.1.1.2.~ 2014-02-18 10:36:03.000000000 -0500 --- gdb.texinfo 2014-05-15 13:50:23.000205000 -0400 *************** *** 39082,39087 **** --- 39083,39094 ---- Refer to @ref{thread-id syntax}, for the format of the @var{thread-id} fields. + @emph{Note: @value{GDBN} will send the @code{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 @code{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
> cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> > Date: Thu, 15 May 2014 13:55:53 -0400 > From: David Taylor <dtaylor@emc.com> > > Here's the revised patch: > > *** gdb.texinfo.~1.1.1.2.~ 2014-02-18 10:36:03.000000000 -0500 > --- gdb.texinfo 2014-05-15 13:50:23.000205000 -0400 > *************** > *** 39082,39087 **** > --- 39083,39094 ---- > Refer to @ref{thread-id syntax}, for the format of the @var{thread-id} > fields. > > + @emph{Note: @value{GDBN} will send the @code{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 @code{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 Thanks, I pushed this in your name.
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