From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13276 invoked by alias); 13 Sep 2008 01:28:02 -0000 Received: (qmail 13263 invoked by uid 22791); 13 Sep 2008 01:28:01 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 13 Sep 2008 01:27:03 +0000 Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id m8D1Qv7N002554 for ; Sat, 13 Sep 2008 02:26:57 +0100 Received: from rv-out-0708.google.com (rvfc5.prod.google.com [10.140.180.5]) by wpaz24.hot.corp.google.com with ESMTP id m8D1Qtdk026092 for ; Fri, 12 Sep 2008 18:26:56 -0700 Received: by rv-out-0708.google.com with SMTP id c5so1024598rvf.34 for ; Fri, 12 Sep 2008 18:26:55 -0700 (PDT) Received: by 10.141.163.12 with SMTP id q12mr3002638rvo.260.1221269215602; Fri, 12 Sep 2008 18:26:55 -0700 (PDT) Received: by 10.141.26.7 with HTTP; Fri, 12 Sep 2008 18:26:55 -0700 (PDT) Message-ID: Date: Sat, 13 Sep 2008 01:28:00 -0000 From: "Cary Coutant" To: gcc Subject: gdb test suite failure on i386 and x86_64 in gdb.base/break.exp Cc: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00075.txt.bz2 There are a couple of failures in the gdb test suite on i386 and x86_64 with gcc 4.3.0 or newer. The tests gdb.base/break.exp and gdb.base/sepdebug.exp are failing with a function begins with a while loop. The into_cfg_layout_mode pass was added in 4.3.0 (see http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00687.html), and that pass removes the instruction that jumps from the end of the first basic block to the bottom of the while loop. The outof_cfg_layout_mode pass reintroduces the branch (in force_nonfallthru_and_redirect) once the basic blocks have been laid out, but the source location information has been lost by that point. When you try to set a breakpoint at the beginning of the function, gdb looks for the second row in the line table (it skips the first to get past the prologue), and sets the breakpoint there. Because of the missing locator on the jump, the second row is now the interior of the while loop, and the breakpoint is in the wrong place. Here's a reduced test case: void foo(int a) { while (a) { // line 3 a--; // line 4 } } If you compile this (for x86_64) with a top-of-trunk gcc with -S -g, you can see that the jmp to .L2 has no .loc directive in front of it, and the first .loc directive is now the one for the body of the while loop: .file 1 "foo.cc" .loc 1 1 0 pushq %rbp .LCFI0: movq %rsp, %rbp .LCFI1: movl %edi, -4(%rbp) jmp .L2 .L3: .loc 1 4 0 subl $1, -4(%rbp) .L2: .loc 1 3 0 cmpl $0, -4(%rbp) jne .L3 .loc 1 6 0 leave ret For comparison, here's the output from gcc 4.2.1: .file 1 "foo.cc" .loc 1 1 0 pushq %rbp .LCFI0: movq %rsp, %rbp .LCFI1: movl %edi, -4(%rbp) .loc 1 3 0 jmp .L2 .L3: .loc 1 4 0 subl $1, -4(%rbp) .L2: .loc 1 3 0 cmpl $0, -4(%rbp) jne .L3 .loc 1 6 0 leave ret I've tried changing force_nonfallthru_and_redirect (in cfgrtl.c) to use to e->goto_locus field as the location for the reintroduced jump, but that seems to mark the jump with line #6 (goto_locus might not even be valid yet at this point, I'm told, and I'm not even sure that a locus can be used where an INSN_LOCATOR is expected -- the location_from_locus macro was removed). I've also tried looking through the target bb's instruction list to find the first instruction with an INSN_LOCATOR and using that for the locator of the jump -- it fixed this problem, but broke other tests because now a forward branch in other contexts (if-then-else, for example) gets the line number of its target, and gdb will now use that branch as the breakpoint location for that line number. I'd argue that gcc really ought to be flagging the end of the prologue -- there's a debug hook for that, and it's used by most of the debug formats, but not by DWARF. The DWARF spec was extended (in version 3) to allow the line number table to indicate the end of prologue, so gcc (and gas) ought to be updated to record it in the line table, and gdb ought to be taught to use that in lieu of looking for the second row in the line table. Until all that happens, though, I think a quicker fix is necessary. Any suggestions? -cary