From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@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 15:03:00 -0000 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-SW-Source: 2004-08/txt/msg00505.txt.bz2 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