From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90801 invoked by alias); 22 Sep 2015 00:11:29 -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 90791 invoked by uid 89); 22 Sep 2015 00:11:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no 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; Tue, 22 Sep 2015 00:11:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id D9394341AC2 for ; Tue, 22 Sep 2015 00:11:25 +0000 (UTC) Received: from pinnacle.lan (ovpn-113-104.phx2.redhat.com [10.3.113.104]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8M0BPJK001472 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO) for ; Mon, 21 Sep 2015 20:11:25 -0400 Date: Tue, 22 Sep 2015 00:11:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Subject: Re: [PATCH 1/8] Add new test, gdb.base/loop-break.exp Message-ID: <20150921171124.42784894@pinnacle.lan> In-Reply-To: <20150818235756.23c9d7db@pinnacle.lan> References: <20150818235334.1afb0c85@pinnacle.lan> <20150818235756.23c9d7db@pinnacle.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00520.txt.bz2 The test case for loop-break.exp contains some code which performs looping via gotos: volatile int v; ... 48 v = 0; 49 goto b; /* Loop 4 initial goto */ 50 a: v++; 51 b: if (v < 3) goto a; /* Loop 4 condition */ While testing on arm and powerpc, I'm seeing this failure: FAIL: gdb.base/loop-break.exp: continue to Loop 4 condition, 3 (the program exited) The test places a breakpoint on lines 49 and 51. We expect the breakpoint at line 49 to be hit once and the breakpoint at line 51 to be hit four times, with v assuming the values 0, 1, 2, and 3 at successive stops at this breakpoint. For both arm and powerpc, the breakpoint on line 51 is being hit only three times; the breakpoint is not being hit when v = 3. In order to figure out what's going on, I placed breakpoints on lines 48, 49, 50, and 51. Here's the assembly code for arm with annotations showing the location of each breakpoint. I've adjusted GDB's output somewhat to better fit in 80 columns (without wrapping) along with providing a more informative comment regarding v. 0x833c : ldr r3, [pc, #64] ; v # line 48 bkpt 0x8340 : mov r2, #0 0x8344 : str r2, [r3] 0x8348 : b 0x8364 # line 49 bkpt 0x834c : nop # line 51 bkpt 0x8350 : ldr r3, [pc, #44] ; v # line 50 bkpt 0x8354 : ldr r3, [r3] 0x8358 : add r3, r3, #1 0x835c : ldr r2, [pc, #32] ; v 0x8360 : str r3, [r2] 0x8364 : ldr r3, [pc, #24] ; v # Loop 4 Cond 0x8368 : ldr r3, [r3] 0x836c : cmp r3, #2 0x8370 : ble 0x834c 0x8374 : nop The locations for breakpoints for line 48, 49, and 50 are not surprising; these are exactly where I would expect them to be. The breakpoint for line 51 is placed on the nop instruction immediately following the branch. This nop is the branch destination for the conditional branch at the bottom of the loop. As such, the breakpoint at line 51 will only be hit after evaluation of the condition, but immediately before the increment on line 50. The correct location for a breakpoint on line 51 is 0x8364, which I've annotated with "Loop 4 Cond". I've performed an analysis for powerpc too; the code being generated is the same (modulo the differences in instruction sets) as that of arm. The .debug_line section contains these statements for this section of code: [0x0000016c] Special opcode 68: advance Address by 8 to 0x833c and Line by 7 to 48 [0x0000016d] Special opcode 90: advance Address by 12 to 0x8348 and Line by 1 to 49 [0x0000016e] Special opcode 35: advance Address by 4 to 0x834c and Line by 2 to 51 [0x0000016f] Special opcode 32: advance Address by 4 to 0x8350 and Line by -1 to 50 [0x00000170] Special opcode 146: advance Address by 20 to 0x8364 and Line by 1 to 51 It's not clear to me why the nop is considered to be part of line 51. This might make (some) sense if either architecture had branch delay slots, but to the best of my knowledge they do not. In any case, things would work correctly if the statement at 0x0000016e were removed. Kevin