Re: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers

[Andrew Cagney <cagney@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 141 bytes --]

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

[-- Attachment #2: Attached Message --]
[-- Type: message/rfc822, Size: 6425 bytes --]

From: Mark Kettenis <kettenis@chello.nl>
To: gdb-patches@sources.redhat.com
Subject: [PATCH/RFA] Don't apply line-number tweaks for non-GCC compilers
Date: Sat, 14 Aug 2004 17:03:08 +0200 (CEST)
Message-ID: <200408141503.i7EF38O5004624@elgar.kettenis.dyndns.org>

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  <kettenis@gnu.org>
 
	* 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