From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8251 invoked by alias); 22 Nov 2012 16:09:49 -0000 Received: (qmail 8241 invoked by uid 22791); 22 Nov 2012 16:09:46 -0000 X-SWARE-Spam-Status: No, hits=-3.7 required=5.0 tests=AWL,BAYES_00,FROM_12LTRDOM,KHOP_RCVD_UNTRUST,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Nov 2012 16:09:40 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1TbZLP-0001h1-HG from Yao_Qi@mentor.com for gdb@sourceware.org; Thu, 22 Nov 2012 08:09:39 -0800 Received: from SVR-ORW-FEM-02.mgc.mentorg.com ([147.34.96.206]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Nov 2012 08:09:39 -0800 Received: from qiyao.dyndns.org (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.1.289.1; Thu, 22 Nov 2012 08:09:38 -0800 Message-ID: <50AE4E3D.8000701@codesourcery.com> Date: Thu, 22 Nov 2012 16:09:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120911 Thunderbird/15.0.1 MIME-Version: 1.0 To: "gdb@sourceware.org" Subject: gdb in non-stop/sync mode connects to gdbserver Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes 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 X-SW-Source: 2012-11/txt/msg00064.txt.bz2 Hello, When running moribund-step.exp with boardfile 'unix', we'll get two passes, PASS: gdb.base/moribund-step.exp: set non-stop on PASS: gdb.base/moribund-step.exp: step However, when running it with boardilfe native-gdbserver, we'll get only one pass, PASS: gdb.base/moribund-step.exp: set non-stop on in fact, gdb hang there when connecting to gdbserver. Supposing gdb is in non-stop and sync mode, here is callgraph of functions related to 'connecting to remote gdbserver'. remote_start_remote 1) putpkt ("QNonStop:1"); 2) remote_thread_info | +-> remote_notice_new_inferior | +-> notice_new_inferior | | | +-> target_stop and then wait_for_inferior [A] +-> attach_command_post_wait | + target_stop (in non-stop mode, and no wait) [B] 3) putpkt ("?") 4) init_wait_for_inferior 5) check packet replied to "?", and handle stop reply if needed. After step 1), GDBserver knows that "we are in non-stop mode". In step 2), gdb calls target_stop in [A], sending 'vCont;t' to stop one thread, and expect to get a %Stop notification. However, when gdbserver launches program, the thread has been stopped before gdb connects to gdbserver. So the stop request from gdb is ignored by gdbserver (shown by the gdbserver log below), getpkt ("vCont;t:p45df.45df"); [no ack sent] already stopped LWP 17887 at GDB's request Need step over [LWP 17887]? Ignoring, should remain stopped Resuming, no pending status or step over needed putpkt ("$OK#9a"); [noack mode] and no %Stop notification is sent back to gdb. Then, gdb hang there. The problem is that gdb wants to get a certain thread stopped, but doesn't know its state, so has to blindly force to stop it, and expect a %Stop notification to come. Then, I am wondering if gdbserver can sends the state of threads, if known, to gdb when gdb connects, and gdb don't have to stop threads if they are already stopped. Is it a good way to go? We can achieve this by add new attribute 'state' in the xml returned to qxfer:threads:read. My experiments show it works, but not sure if I miss something important. Doing this is not enough to fix the problem I mentioned at the beginning. There is another problem in the following steps. Supposing gdb doesn't call target_stop in [A], gdb will call target_stop in [B], GDB GDBserver [B] 'vCont;t' -> <- 'OK' 3) '?' -> <- 'T0505:xxxxx' 4) 5) process stop reply and send 'vStopped' 'vStopped' -> <- 'OK' This process requires that there is no packet sent in step 4), because gdb is expecting to get a stop reply. Unfortunately, breakpoint_init_inferior, called by init_wait_for_inferior, has to access inferior memory, so 'm' packet is sent out. Looks like the fix to this problem is to move all functions which cause sending packets in step 4) after step 5). Does it sound a good idea? I've got a patch to fix the two problems, but I am not sure it is on a right direction. If it is correct, I'll polish the patch, and post it. -- Yao (齐尧)