This is the mail archive of the gdb-patches@sources.redhat.com 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]

[RFA] Don't apply line-number tweaks for non-GCC compilers


   From: Jim Blandy <jimb@redhat.com>
   Date: 17 Oct 2004 14:57:22 -0500

[Oops.  Now with ChangeLog.]

   Elena Zannoni <ezannoni@redhat.com> writes:
   > 
   > Jim, send a list of pointers (with URLs) to the patches and I'll take
   > care of them.

   Okay, great.  Here are the ones that I know about:

   - GDB's stabs reader tweaks line number information, in a way that's
     not appropriate for non-GCC stabs.  Mark Kettenis posted a patch,
     and I suggested a revision; I think that's where it stands.

       http://sources.redhat.com/ml/gdb-patches/2004-09/msg00234.html

I had a follow-up patch, but I lost it when I accidentally did an rm
-rf of my GDB working directory.  Anyway, here's a new one that
implements Jim's suggestion.  OK?

I'd really like to check this in on the new release branch too, since
I promised to fix this a long time ago.

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.74
diff -u -p -r1.74 dbxread.c
--- dbxread.c 11 Sep 2004 10:24:46 -0000 1.74
+++ dbxread.c 19 Oct 2004 20:45:53 -0000
@@ -2927,11 +2927,26 @@ 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.  */
+
       if (within_function && sline_found_in_function == 0)
 	{
-	  record_line (current_subfile, desc, last_function_start);
+	  if (processing_gcc_compilation == 2)
+	    record_line (current_subfile, desc, last_function_start);
+	  else
+	    record_line (current_subfile, desc, valu);
 	  sline_found_in_function = 1;
 	}
       else


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