From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16281 invoked by alias); 16 Jun 2009 18:39:19 -0000 Received: (qmail 16272 invoked by uid 22791); 16 Jun 2009 18:39:18 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS 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.43rc1) with ESMTP; Tue, 16 Jun 2009 18:39:11 +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 n5GId8SQ005899 for ; Tue, 16 Jun 2009 19:39:08 +0100 Received: from yw-out-1718.google.com (ywq4.prod.google.com [10.192.17.4]) by wpaz24.hot.corp.google.com with ESMTP id n5GId5Bp025716 for ; Tue, 16 Jun 2009 11:39:05 -0700 Received: by yw-out-1718.google.com with SMTP id 4so2166166ywq.88 for ; Tue, 16 Jun 2009 11:39:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.110.2 with SMTP id i2mr11130727anc.76.1245177545445; Tue, 16 Jun 2009 11:39:05 -0700 (PDT) Date: Tue, 16 Jun 2009 18:39:00 -0000 Message-ID: Subject: DWARF is_stmt flag (revisited) From: Cary Coutant To: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-System-Of-Record: true X-IsSubscribed: yes 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 X-SW-Source: 2009-06/txt/msg00406.txt.bz2 Daniel Jacobowitz posted a patch for discussion last October to make gdb ignore line table rows where is_stmt == 0: http://sourceware.org/ml/gdb-patches/2008-10/msg00055.html There are still a couple of remaining testsuite failures that are triggered by the new discriminator support in gcc, and fixing these failures is going to require that gcc emit line table entries where is_stmt == 0. The problem is that the new line table row that gcc adds to change the discriminator is now seen as a new potential breakpoint location, and a place to stop when single-stepping. The solution is to change gcc so that any new rows to set the discriminator (that would not otherwise have been emitted) should have is_stmt == 0, and for gdb to ignore such rows. The patch below is almost the same as Daniel's original patch; I also fixed a bug where the basic_block flag was being initialized to the wrong value after a special opcode. Longer term, I think that gdb will need to record the is_stmt flag with each line table row, so that it can provide accurate pc -> line number mappings for optimized code, while still ignoring !is_stmt lines when setting breakpoints and single-stepping. The compiler will eventually need to start using the is_stmt flag when scheduling causes the line number to hop around, so that we don't stop multiple times on one line of code. Tested on x86_64. No new regressions with a compiler that does not set is_stmt == 0. OK for trunk? -cary * dwarf2read.c (dwarf_decode_lines): Ignore rows where is_stmt is 0. Set basic_block to 0 after a special opcode. Index: dwarf2read.c =================================================================== RCS file: /cvs/src/src/gdb/dwarf2read.c,v retrieving revision 1.308 diff -u -p -r1.308 dwarf2read.c --- dwarf2read.c 13 Jun 2009 04:23:34 -0000 1.308 +++ dwarf2read.c 16 Jun 2009 18:26:52 -0000 @@ -7318,7 +7318,7 @@ dwarf_decode_lines (struct line_header * else { lh->file_names[file - 1].included_p = 1; - if (!decode_for_pst_p) + if (!decode_for_pst_p && is_stmt) { if (last_subfile != current_subfile) { @@ -7331,7 +7331,7 @@ dwarf_decode_lines (struct line_header * check_cu_functions (address, cu)); } } - basic_block = 1; + basic_block = 0; } else switch (op_code) { @@ -7396,7 +7396,7 @@ dwarf_decode_lines (struct line_header * else { lh->file_names[file - 1].included_p = 1; - if (!decode_for_pst_p) + if (!decode_for_pst_p && is_stmt) { if (last_subfile != current_subfile) {