From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1475 invoked by alias); 1 May 2014 20:54:09 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 1463 invoked by uid 89); 1 May 2014 20:54:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,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, 01 May 2014 20:54:05 +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 s41Ks2Bf030307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 May 2014 16:54:02 -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, 1 May 2014 16:53:44 -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 s41KrhYV021600 for ; Thu, 1 May 2014 16:53:43 -0400 Received: by usendtaylorx2l.lss.emc.com (Postfix, from userid 26043) id D6F825C6C4D; Thu, 1 May 2014 16:53:42 -0400 (EDT) Received: from usendtaylorx2l (localhost [127.0.0.1]) by usendtaylorx2l.lss.emc.com (Postfix) with ESMTP id D3F245C6C4C for ; Thu, 1 May 2014 16:53:42 -0400 (EDT) From: David Taylor To: gdb@sourceware.org Subject: counter intuitive remote target behavior in GDB 7.7 Date: Thu, 01 May 2014 20:54:00 -0000 Message-ID: <3354.1398977622@usendtaylorx2l> X-EMM-MHVC: 1 X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00000.txt.bz2 I'm seeing some counter intuitive remote target behavior in GDB 7.7. We're writing a new GDB stub to replace our old GDB stub and there are some behaviors by GDB that seem counter intuitive when talking to the remote target. I start GDB with an ELF file, I set debug packet (so I can see the behavior I'm describing here), target-async, non-stop, turn off paging (set height 0) and then I do a target remote with appropriate arguments. NOTE: remote, not extended-remote. We might support extended-remote in the future, but not yet. GDB sends a qSupported packet; we respond saying what we support; GDB is happy with the response. GDB sends Hg0 (select any thread), we say OK. GDB sends QNonStop:1, we say OK, GDB sends qfThreadInfo, we respond with a list of 50+ thread ids (the example in front of me has 65 thread ids). qAttached -- we respond '1' (yes, we support qAttached, no you didn't create the process / thread that you are attached to). vCont? -- we respond with vCont;c;C;s;S;t Everything is fine so far; *BUT*, notably, GDB has NOT asked what thread it got when it did the Hg0 -- no qC packet has been seen. GDB now does a vCont;t:1 To which I want to say WTF? It *IS* okay for the user to explicitly and intentionally stop thread 1 or *MOST* threads on the system. If you explicitly stop a thread and you screw yourself, well it's your fault -- be more careful next time. It is *NOT* okay for GDB to 'randomly' decide to stop thread 1 (or any other thread for that matter). When Hg0 was received the stub selected a good thread for GDB to stop (in fact, the thread is likely already stopped). GDB now does qsThreadInfo to get the rest of the thread list. Then a qTStatus (T0;tnotrun:0 for the example in front of me), qTfV (empty -- no thread state variables yet in the new stub). Then '?' and a sequence of vStopped packets to get the list of currently stopped threads. *FINALLY* GDB issues a qC to which, in this instance we respond with QC41 -- thread 65. Then it's qOffsets, qSymbol, another qTStatus, and a qTfP. Next it does a Hg1 (the first stopped thread -- stopped only because GDB decided to stop it!); reads the thread's registers, and reads memory at the current pc location. Then 4 qTStatus messages within nothing in between. Then it goes through each of the remaining stopped threads, reads the registers and the memory at the stopped pc location. To summarize -- It asked the stub to pick a current thread; which the stub did. It eventually asked the stub which thread it picked -- never using the result; but not until after first stopping a thread of its own choosing. It then changed the current thread several times -- throwing away the thread selection that was done initially. And it did a total of 6 qTStatus messages -- 4 of them without any other messages in between. Comments anyone?