From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12247 invoked by alias); 3 Mar 2012 15:17:07 -0000 Received: (qmail 12236 invoked by uid 22791); 3 Mar 2012 15:17:05 -0000 X-SWARE-Spam-Status: No, hits=-6.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Mar 2012 15:16:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q23FGmIA012798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 3 Mar 2012 10:16:48 -0500 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q23FGl6a025374; Sat, 3 Mar 2012 10:16:47 -0500 Message-ID: <4F5235DE.9060003@redhat.com> Date: Sat, 03 Mar 2012 15:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Jan Kratochvil CC: gdb-patches@sourceware.org Subject: Re: [obv] testsuite: disp-step-syscall.exp: Setup KFAIL for PR server/13796 References: <20120303070105.GA13581@host2.jankratochvil.net> In-Reply-To: <20120303070105.GA13581@host2.jankratochvil.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2012-03/txt/msg00115.txt.bz2 On 03/03/2012 07:01 AM, Jan Kratochvil wrote: > Hi, > > [patch] Fix disp-step-syscall.exp on some i386 targets > http://sourceware.org/ml/gdb-patches/2012-02/msg00635.html > > just fixed a testcase which revealed existing IMO gdbserver Bug, therefore > just KFAILed it. > > stepi > Program terminated with signal SIGILL, Illegal instruction. > The program no longer exists. > (gdb) PASS: gdb.base/disp-step-syscall.exp: vfork: single step over vfork > Child terminated with signal = 0x4 (SIGILL) > GDBserver exiting > print /x $pc > No registers. > (gdb) FAIL: gdb.base/disp-step-syscall.exp: vfork: get hexadecimal valueof "$pc" (timeout) I've analized this one before. The issue is that the test displace-steps over a vfork syscall. In the special case of displace-stepping over a fork, GDB needs to adjust both the parent and the child back from the displace stepping scratchpad. Since GDBserver doesn't support following (v)forks yet, gdb is never informed about the child, and so the child ends up continuing freely, unadjusted, from the scratchpad, and crashes. So this is all really about the remote protocol not supporting following forks yet. -- Pedro Alves