From patchwork Thu Jul 30 04:05:50 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sandra Loosemore X-Patchwork-Id: 7930 Received: (qmail 55763 invoked by alias); 30 Jul 2015 04:07:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 55750 invoked by uid 89); 30 Jul 2015 04:07:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Jul 2015 04:07:48 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1ZKf8D-0003yy-Hq from Sandra_Loosemore@mentor.com for gdb-patches@sourceware.org; Wed, 29 Jul 2015 21:07:45 -0700 Received: from [IPv6:::1] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.224.2; Wed, 29 Jul 2015 21:07:44 -0700 Message-ID: <55B9A29E.4040305@codesourcery.com> Date: Wed, 29 Jul 2015 22:05:50 -0600 From: Sandra Loosemore User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: Subject: [patch, testsuite] further robustify gdb.base/bp-permanent.exp When I was testing the Nios II R2 patch I posted earlier today, I saw a lot of failures from gdb.base/bp-permanent.exp. Upon investigation, I realized that this was a due to a quirk of the simulator we have available. Apparently, its execution engine maintains its own view of the .text section and breakpoints set through the debug interface are not visible to the running program. This means that the setup function in the program is stashing away a copy of the original NOP instruction at the breakpoint location, rather than the breakpoint instruction inserted by GDB, and when the .exp file thinks it is writing a permanent breakpoint in fact it is just telling the target to write a NOP to a location that already contains one. :-S Anyway, it is clear that if the program runs to termination instead of stopping where GDB expects, none of the remaining tests are going to do anything useful, so we might just as well report that the test is unsupported and return. OK to commit? -Sandra diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp index cbdbc75..44609ed 100644 --- a/gdb/testsuite/gdb.base/bp-permanent.exp +++ b/gdb/testsuite/gdb.base/bp-permanent.exp @@ -123,8 +123,21 @@ proc test {always_inserted sw_watchpoint} { with_test_prefix "basics" { # Run to the permanent breakpoint, just to make sure we've inserted it # correctly. - gdb_test "continue" "Program received signal SIGTRAP.*" \ - "permanent breakpoint causes random signal" + # If the target fails to stop, the remainder of the test will not work + # so just return. This can happen on some simulator targets where + # the running program doesn't see breakpoints that are visible to + # the execution engine, or where writes to the .text section are + # quietly ignored. + set test "permanent breakpoint causes random signal" + gdb_test_multiple "continue" $test { + -re "exited normally.*$gdb_prompt $" { + unsupported "failed to stop at permanent breakpoint" + return + } + -re "Program received signal SIGTRAP.*" { + pass $test + } + } # Now set a breakpoint on top, thus creating a permanent breakpoint. gdb_breakpoint "$line_bp"