This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.

--- Begin Message ---
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.



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

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;

--- End Message ---

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]