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

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

[Mark Kettenis]

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

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

[Andrew Cagney]

[-- 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

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

[Jim Blandy]

Mark Kettenis <kettenis@chello.nl> writes:
> 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?

(Thanks for finding this, Andrew.)

Is there any reason you're not testing processing_gcc_compilation,
instead of checking the last N_FUN's desc?

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

[Mark Kettenis]

   From: Jim Blandy <jimb@redhat.com>
   Date: 20 Sep 2004 16:44:33 -0500

[ That earned you a nice bounce I suppose.  I've moved, and therefore
  got rid of my cable.  On the bright side, I've now got a decent ISP
  and a fixed IP address. ]

   Mark Kettenis <kettenis@chello.nl> writes:
   > 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?

   (Thanks for finding this, Andrew.)

   Is there any reason you're not testing processing_gcc_compilation,
   instead of checking the last N_FUN's desc?

Other than that it's a global variable?  No not really.  I suppose it
was because the patch actually is a slimmed down version of a patch
that tried (and failed) to distinguish between a broken GCC and a
fixed GCC too.

Do you prefer checking processing_gcc_compilation?  I suppose it's
better because it makes the intent clearer.

Mark

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

[Jim Blandy]

Mark Kettenis <kettenis@sibelius.xs4all.nl> writes:
>    From: Jim Blandy <jimb@redhat.com>
>    Date: 20 Sep 2004 16:44:33 -0500
> 
> [ That earned you a nice bounce I suppose.  I've moved, and therefore
>   got rid of my cable.  On the bright side, I've now got a decent ISP
>   and a fixed IP address. ]
> 
>    Mark Kettenis <kettenis@chello.nl> writes:
>    > 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?
> 
>    (Thanks for finding this, Andrew.)
> 
>    Is there any reason you're not testing processing_gcc_compilation,
>    instead of checking the last N_FUN's desc?
> 
> Other than that it's a global variable?  No not really.  I suppose it
> was because the patch actually is a slimmed down version of a patch
> that tried (and failed) to distinguish between a broken GCC and a
> fixed GCC too.
> 
> Do you prefer checking processing_gcc_compilation?  I suppose it's
> better because it makes the intent clearer.

Yes, I'd prefer that.  I see processing_gcc_compilation as one of the
global variables used to communicate with buildsym.c, like the context
stack, the subfile stack, and so on.