From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18183 invoked by alias); 14 Sep 2004 20:05:57 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18163 invoked from network); 14 Sep 2004 20:05:56 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 14 Sep 2004 20:05:56 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.10) with ESMTP id i8EK5ov8023054 for ; Tue, 14 Sep 2004 16:05:51 -0400 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i8EK5lr32494; Tue, 14 Sep 2004 16:05:47 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id EF40828D2; Tue, 14 Sep 2004 16:03:33 -0400 (EDT) Message-ID: <41474E95.4090409@gnu.org> Date: Tue, 14 Sep 2004 20:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040831 MIME-Version: 1.0 To: Mark Kettenis , gdb-patches@sources.redhat.com, Jim Blandy , Michael Elizabeth Chastain Subject: Re: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers References: <200408141503.i7EF38O5004624@elgar.kettenis.dyndns.org> In-Reply-To: <200408141503.i7EF38O5004624@elgar.kettenis.dyndns.org> Content-Type: multipart/mixed; boundary="------------080502030001080706090207" X-SW-Source: 2004-09/txt/msg00234.txt.bz2 This is a multi-part message in MIME format. --------------080502030001080706090207 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 141 I just stumbled across this. The patch doesn't appear to be committed. Hmm wonder if it can be tested with a gdb.stabs addition. Andrew --------------080502030001080706090207 Content-Type: message/rfc822; name="Attached Message" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Attached Message" Content-length: 6404 Return-Path: Delivered-To: cagney@localhost.redhat.com Received: from localhost (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 520A72B9D for ; Mon, 23 Aug 2004 08:42:07 -0400 (EDT) Envelope-to: cagney@gnu.org Delivery-date: Sat, 14 Aug 2004 11:09:58 -0400 Received: from fencepost.gnu.org by localhost with IMAP (fetchmail-6.2.4) for cagney@localhost (single-drop); Mon, 23 Aug 2004 08:42:07 -0400 (EDT) Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.34) id 1Bw0AQ-0004eb-Lo for cagney@gnu.org; Sat, 14 Aug 2004 11:09:58 -0400 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.34) id 1Bw0AM-0005It-SW for cagney@gnu.org; Sat, 14 Aug 2004 11:09:55 -0400 Received: from [12.107.209.250] (helo=sourceware.org) by monty-python.gnu.org with smtp (Exim 4.34) id 1Bw0AM-0005Ip-GV for cagney@gnu.org; Sat, 14 Aug 2004 11:09:54 -0400 Received: (qmail 26427 invoked by alias); 14 Aug 2004 15:03:11 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Delivered-To: mailing list gdb-patches@sources.redhat.com Received: (qmail 26415 invoked from network); 14 Aug 2004 15:03:10 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sourceware.org with SMTP; 14 Aug 2004 15:03:10 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i7EF39XS000878 for ; Sat, 14 Aug 2004 17:03:09 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i7EF395i004627 for ; Sat, 14 Aug 2004 17:03:09 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i7EF38O5004624; Sat, 14 Aug 2004 17:03:08 +0200 (CEST) Date: Sat, 14 Aug 2004 17:03:08 +0200 (CEST) Message-Id: <200408141503.i7EF38O5004624@elgar.kettenis.dyndns.org> From: Mark Kettenis To: gdb-patches@sources.redhat.com Subject: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers X-Spam-Status: No, hits=1.5 required=5.0 tests=RCVD_IN_NJABL,RCVD_IN_ORBS,X_NJABL_DIALUP version=2.55 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) Content-length: 3409 The line-number tweaks we do for the sake of GCC 2.95.3 mess up the line number info for non-GCC compilers that emit stabs. In particular this makes it annoying to debug code using the Sun compilers on SPARC. This patch attempts to fix that. Please refer to the comment in the code for details. I deliberately did not remove the while line-number hack. In the end that's what we should really do, but I still do most of my GDB work on systems that have GCC 2.95.3 as their default compiler, and I really like being able to run the testsuite on those platforms. OK? Mark Index: ChangeLog from Mark Kettenis * dbxread.c (process_one_symbol): Do not adjust address of first N_SLINE stab for a function for code generated by non-GCC compilers. Index: dbxread.c =================================================================== RCS file: /cvs/src/src/gdb/dbxread.c,v retrieving revision 1.72 diff -u -p -r1.72 dbxread.c --- dbxread.c 10 Aug 2004 21:52:04 -0000 1.72 +++ dbxread.c 14 Aug 2004 14:58:11 -0000 @@ -2660,6 +2660,9 @@ process_one_symbol (int type, int desc, peculiarities of function_start_offset. */ static CORE_ADDR last_function_start; + /* The stab description field for the last N_FUN stab. */ + static int last_function_desc; + /* If this is nonzero, we've seen an N_SLINE since the start of the current function. We use this to tell us to move the first sline to the beginning of the function regardless of what its given @@ -2736,6 +2739,7 @@ process_one_symbol (int type, int desc, valu += ANOFFSET (section_offsets, SECT_OFF_TEXT (objfile)); valu = SMASH_TEXT_ADDRESS (valu); last_function_start = valu; + last_function_desc = desc; goto define_a_symbol; @@ -2928,11 +2932,30 @@ process_one_symbol (int type, int desc, /* Relocate for dynamic loading and for ELF acc fn-relative syms. */ valu += function_start_offset; - /* If this is the first SLINE note in the function, record it at - the start of the function instead of at the listed location. */ + /* GCC 2.95.3 emits the first N_SLINE stab somwehere in the + middle of the prologue instead of right at the start of the + function. To deal with this we record the address for the + first N_SLINE stab to be the start of the function instead of + the listed location. We really shouldn't to this. When + compiling with optimization, this first N_SLINE stab might be + optimized away. Other (non-GCC) compilers don't emit this + stab at all. There is no real harm in having an extra + numbered line, although it can be a bit annoying for the + user. However, it totally screws up our testsuite. + + So for now, keep adjusting the address of the first N_SLINE + stab, but only for code compiled with GCC. We distinguish + between GCC and non-GCC by looking at the descritpion field + of the N_FUN stab corresponding to the function we're in. + GCC sets that field to the line number of the function start. + Other compilers leave it at zero. */ + if (within_function && sline_found_in_function == 0) { - record_line (current_subfile, desc, last_function_start); + if (last_function_desc != 0) + record_line (current_subfile, desc, last_function_start); + else + record_line (current_subfile, desc, valu); sline_found_in_function = 1; } else --------------080502030001080706090207--