From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50921 invoked by alias); 8 Apr 2015 10:17:50 -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 50792 invoked by uid 89); 8 Apr 2015 10:17:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 08 Apr 2015 10:17:47 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3DF378E3E9; Wed, 8 Apr 2015 10:17:46 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t38AHibk028390; Wed, 8 Apr 2015 06:17:45 -0400 Message-ID: <55250048.9050801@redhat.com> Date: Wed, 08 Apr 2015 10:17:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH v2 00/23] All-stop on top of non-stop References: <1428410990-28560-1-git-send-email-palves@redhat.com> <86mw2jvtqk.fsf@gmail.com> In-Reply-To: <86mw2jvtqk.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00260.txt.bz2 On 04/08/2015 10:45 AM, Yao Qi wrote: > Pedro Alves writes: > >> While v1 had only been tested on x86-64 GNU/Linux, v2 was tested on: >> >> x86-64 GNU/Linux >> x86-64 GNU/Linux on top of software single-step branch >> PPC64 GNU/Linux >> S/390 GNU/Linux > > Hi Pedro, > I tested this patch series on arm GNU/Linux, both native and gdbserver. > Overall, the results look pretty good, here are some fails > exposed/caused by this series. I'd like to post them first today and > take a look at this series then. > > 1, on gdbserver, > -UNSUPPORTED: gdb.mi/mi-dprintf.exp: send dprintf to target > +FAIL: gdb.mi/mi-dprintf.exp: mi expect stop (unknown output after running) > +FAIL: gdb.mi/mi-dprintf.exp: mi 1st dprintf, agent (unknown output after running) > +FAIL: gdb.mi/mi-dprintf.exp: mi info dprintf second time > +FAIL: gdb.mi/mi-dprintf.exp: mi 2nd dprintf, agent (timeout) > > BEFORE: > 220-exec-continue^M > 220^error,msg="Warning:\nCannot insert breakpoint 3: Target doesn't support breakpoints that have target side commands.\nCannot insert breakpoint 4: Target doesn't support breakpoints that have target side commands.\n"^M > (gdb) ^M > UNSUPPORTED: gdb.mi/mi-dprintf.exp: send dprintf to target > > AFTER: > 220-exec-continue^M > 220^running^M > *running,thread-id="all"^M > (gdb) ^M > > I think that is the mi-dprintf.exp issue, which doesn't detect target > dprintf support correctly. Sounds like it. Though I can't see how the series could have changed the result. Maybe it's racy. Passes for me with x86_64 gdbserver with and without software single-step. > > 2, on gdbserver, > +FAIL: gdb.threads/thread-find.exp: find lwp id 6 > +FAIL: gdb.threads/thread-find.exp: find lwp id 5 > +FAIL: gdb.threads/thread-find.exp: find lwp id 4 > +FAIL: gdb.threads/thread-find.exp: find lwp id 3 > +FAIL: gdb.threads/thread-find.exp: find lwp id 2 > +FAIL: gdb.threads/thread-find.exp: find lwp id 1 > thread find 18340^M > No threads match '18340'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 6 > thread find 18339^M > No threads match '18339'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 5 > thread find 18338^M > No threads match '18338'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 4 > thread find 18337^M > No threads match '18337'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 3 > thread find 18336^M > No threads match '18336'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 2 > thread find 18333^M > No threads match '18333'^M > (gdb) FAIL: gdb.threads/thread-find.exp: find lwp id 1 > How odd. Passes for me with x86_64 gdbserver+sss. The "find lwp id" messages indicate that this: if { [info exists lwp6] } then { gdb_test "echo $lwp6\\n" "$lwp6" "got lwp ids" } ... was reached. Are you running the testsuite with two boards at the same time? In that case, I'd guess that the test first ran against the native target, which left $lwp6 set, and then it run against gdbserver, with $lwp6 stale. > Maybe, thread list in GDB side is out of date? Don't think so, there are a bunch of "info threads" calls. > > 3, on native, > -PASS: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > +FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 > > continue^M > Continuing.^M > ^M > Program received signal SIGSEGV, Segmentation fault.^M > 0x40021564 in ?? () gdb/testsuite/gdb.base/info-shared-solib1.so^M > (gdb) FAIL: gdb.base/info-shared.exp: continue to breakpoint: library function #4 Most of the SIGSEGV/SIGILL/SIGBUS inferior crashes I saw were due to a displaced stepping bug. Force disabling displaced stepping with "set displaced off" usually "fixes" it. The next step I would usually take would be to run the test manually, with "set debug infrun 1" + "set debug displaced 1" + "set debug lin-lwp 1". Thanks, Pedro Alves