From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123092 invoked by alias); 15 Nov 2017 23:32:05 -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 123083 invoked by uid 89); 15 Nov 2017 23:32:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy= X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Nov 2017 23:32:02 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id A9A9710A8BA; Wed, 15 Nov 2017 18:32:00 -0500 (EST) From: John Baldwin To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH v3] Add a 'starti' command. Date: Wed, 15 Nov 2017 23:32:00 -0000 Message-ID: <5866637.KqDYZAFHHe@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <20170911220803.73819-1-jhb@FreeBSD.org> <1615021.krJEU3LQPO@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00292.txt.bz2 On Wednesday, November 15, 2017 08:23:41 PM Pedro Alves wrote: > On 11/15/2017 08:11 PM, John Baldwin wrote: > > On Friday, November 03, 2017 01:00:18 PM Yao Qi wrote: > >> John Baldwin writes: > >> > >>> +# Continue to the start of main(). The constructor should have run so > >>> +# 'x' should be 1. > >>> + > >>> +gdb_breakpoint main > >>> +gdb_test_sequence "continue" "" { > >>> + "\\$2 = 1" > >>> + ".*Breakpoint .*main \\(\\) at .*starti.c.*" > >> > >> Here is a test failure, captured by buildbot, > >> https://sourceware.org/ml/gdb-testers/2017-q3/msg04381.html > >> > >> (gdb) gdb_expect_list pattern: /\$2 = 1/ > >> continue^M > >> Continuing.^M > >> $2 = 1^M > >> gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > >> ^M > >> Breakpoint 1, Python Exception Installation error: gdb.execute_unwinders function is missing: ^M > >> main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > >> 29 return 0;^M > >> (gdb) gdb_expect_list pattern: // > >> FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > >> > >> Can you take a look? > > > > Hmm, so it seems the python exception adds a newline which throws the regex > > match off as 'main \(\)' is now on a second line. The 'start.exp' test > > only looks for the 'main' bit and not the preceding 'Breakpoint', so > > something like this instead? > > But is the Python exception expected? From Yao's earlier paste: > > (gdb) gdb_expect_list pattern: /\$2 = 1/ > continue^M > Continuing.^M > $2 = 1^M > gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ > ^M > Breakpoint 1, Python Exception Installation error: gdb.execute_unwinders function is missing: ^M > main () at /home/yao/SourceCode/gnu/gdb/git/gdb/testsuite/gdb.base/starti.c:29^M > 29 return 0;^M > (gdb) gdb_expect_list pattern: // > FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) > > "Installation error" looks quite odd to me. Why did that happen? That I don't know. I think I have seen similar exceptions in the past if the python scripts were not installed to the shared data directory but python was enabled via --with-python. I wouldn't expect a buildbot to be in that situation. I looked at some of the other failures referenced at the URL and found some other results I don't quite understand. For example, for Fedora-x86_64-m32, a test run from earlier today passed starti.exp without issues, but the test linked above failed differently: (gdb) gdb_expect_list pattern: /\$2 = 1/ continue Continuing. $2 = 1 gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ Breakpoint 1, main () at /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c:29 29 return 0; (gdb) gdb_expect_list pattern: // FAIL: gdb.base/starti.exp: continue (pattern 3 + sentinel) (timeout) testcase /home/gdb-buildbot-2/fedora-x86-64-4/fedora-x86-64-m32/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 10 seconds Here the 'Breakpoint' pattern should have matched and it appears that the implicit empty pattern used to match the prompt didn't match? Trying to test the patch I posted earlier today I had an odd failure where 'gdb_breakpoint main' failed, but only the first time I ran the test. The failure seemed to involve expect missing the line confirming the breakpoint was set. Ehen I tried to reproduce this all my other trials of running the modified test succeeded. It does look like the Fedora-i686 test from the link failed in this way, but the failure doesn't make sense to me. It FAILs the setting of the breakpoint before it tries to set the breakpoint: 0xf7fd5ad0 in _start () from /lib/ld-linux.so.2 (gdb) PASS: gdb.base/starti.exp: starti (gdb) FAIL: gdb.base/starti.exp: setting breakpoint at main gdb_expect_list pattern: /\$2 = 1/ break main Breakpoint 1 at 0x80483f9: file /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.c, line 29. (gdb) FAIL: gdb.base/starti.exp: continue (pattern 1) gdb_expect_list pattern: /.*Breakpoint .*main \(\) at .*starti.c.*/ gdb_expect_list pattern: // testcase /home/gdb-buildbot/fedora-x86-64-1/fedora-i686/build/gdb/testsuite/../../../binutils-gdb/gdb/testsuite/gdb.base/starti.exp completed in 0 seconds (Here it never runs "continue" after setting the breakpoint either, though "continue" is the action that has the \$2 = 1 pattern in its list of expected responses.) -- John Baldwin