[RFC]: patch 1 for Sun C compiled target programs

[RFC]: patch 1 for Sun C compiled target programs

[Michael Mueller]

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

Setting a breakpoint on a function name or on the first line of a 
function doesn't work for Sun C compiled target programs (32 and 64 
bit). I verified this against these compiler versions:

   Sun C 5.5 2003/03/12
   Forte Developer 7 C 5.4 2002/03/09
   Sun WorkShop 6 update 2 C 5.3 2001/05/15
   Sun WorkShop 6 2000/04/07 C 5.1

This is what happens:

   GNU gdb 20040614
   Copyright 2004 Free Software Foundation, Inc.
   GDB is free software, covered by the GNU General Public License, and 
you are
   welcome to change it and/or distribute copies of it under certain 
conditions.
   Type "show copying" to see the conditions.
   There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
   This GDB was configured as "sparc-sun-solaris2.8"...
   (gdb) list 1,100
   1       #include <stdio.h>
   2
   3       void fun(void);
   4
   5       int
   6       main()
   7       {
   8         fun();
   9         printf("line %d\n", __LINE__);
   10      }
   11
   12      void
   13      fun()
   14      {
   15        int n = 7;
   16
   17        printf("fun: n = %d\n", n);
   18      }
   (gdb) b main
   Breakpoint 1 at 0x106cc: file p1.c, line 9.
   (gdb) run
   Starting program: /export/home/michaelm/gdb/gdb-6.1.patch/tst/p1
   fun: n = 7

   Breakpoint 1, main () at p1.c:9
   9         printf("line %d\n", __LINE__);
   (gdb) # This is the second line in main!!!
   (gdb) b 8
   Breakpoint 2 at 0x0: file p1.c, line 8.
   (gdb) run
   The program being debugged has been started already.
   Start it from the beginning? (y or n) y

   Starting program: /export/home/michaelm/gdb/gdb-6.1.patch/tst/p1
   Warning:
   Cannot insert breakpoint 2.
   Error accessing memory address 0x0: I/O error.


The reason is that in process_one_symbol the first SLINE address is set 
to last_function_start which is 0 at that time. There are 2 problems (at 
least).

1) last_function_start is set = valu underneath case N_FNAME:, which is 
0. Valu is then corrected after the following goto define_a_symbol;. 
Butlast_function_start remains 0.

2) After correcting that I found that this didn't work either and wasn't 
even necessary  (see patch below). I don't know why this was done in the 
first place and how and for which version this worked. There is this 
comment:

/* If this is the first SLINE note in the function, record it at
    the start of the function instead of at the listed location.  */

Why was this done?

3) last_function_start is used in other places as well. Not sure if this 
now works correctly. Not sure how to test it.

I tested my patch manually against the above compilers.



2004-05-16  Michael Mueller  <m.mueller99@kay-mueller.de>
	* dbxread.c: make breakpoint at function or first
	line of function work

[-- Attachment #2: dbxread.patch --]
[-- Type: text/plain, Size: 2367 bytes --]

Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.67
diff -c -p -r1.67 dbxread.c
*** dbxread.c	10 Jun 2004 20:05:43 -0000	1.67
--- dbxread.c	16 Jun 2004 16:51:05 -0000
*************** process_one_symbol (int type, int desc, 
*** 2672,2680 ****
    static CORE_ADDR last_function_start;
  
    /* 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
!      value is. */
    static int sline_found_in_function = 1;
  
    /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this source
--- 2672,2678 ----
    static CORE_ADDR last_function_start;
  
    /* If this is nonzero, we've seen an N_SLINE since the start of the
!      current function.  */
    static int sline_found_in_function = 1;
  
    /* If this is nonzero, we've seen a non-gcc N_OPT symbol for this source
*************** process_one_symbol (int type, int desc, 
*** 2962,2976 ****
  #ifdef SUN_FIXED_LBRAC_BUG
        last_pc_address = valu;	/* Save for SunOS bug circumcision */
  #endif
-       /* If this is the first SLINE note in the function, record it at
- 	 the start of the function instead of at the listed location.  */
        if (within_function && sline_found_in_function == 0)
- 	{
- 	  record_line (current_subfile, desc, last_function_start);
  	  sline_found_in_function = 1;
! 	}
!       else
! 	record_line (current_subfile, desc, valu);
        break;
  
      case N_BCOMM:
--- 2960,2968 ----
  #ifdef SUN_FIXED_LBRAC_BUG
        last_pc_address = valu;	/* Save for SunOS bug circumcision */
  #endif
        if (within_function && sline_found_in_function == 0)
  	  sline_found_in_function = 1;
!       record_line (current_subfile, desc, valu);
        break;
  
      case N_BCOMM:
*************** process_one_symbol (int type, int desc, 
*** 3117,3123 ****
  		     it is likely that the value was set correctly to begin
  		     with... */
  		  if (minsym_valu != 0)
! 		    valu = minsym_valu;
  		}
  #endif
  
--- 3109,3115 ----
  		     it is likely that the value was set correctly to begin
  		     with... */
  		  if (minsym_valu != 0)
! 		    last_function_start = valu = minsym_valu;
  		}
  #endif
  

Re: [RFC]: patch 1 for Sun C compiled target programs

[Mark Kettenis]

   Date: Wed, 16 Jun 2004 19:57:32 +0200
   From: Michael Mueller <m.mueller99@kay-mueller.de>

   Setting a breakpoint on a function name or on the first line of a 
   function doesn't work for Sun C compiled target programs (32 and 64 
   bit). I verified this against these compiler versions:

      Sun C 5.5 2003/03/12
      Forte Developer 7 C 5.4 2002/03/09
      Sun WorkShop 6 update 2 C 5.3 2001/05/15
      Sun WorkShop 6 2000/04/07 C 5.1

Ah yes.  I knew about this.  Just forgotten all about it.  The funny
code you're seeing is there to work around a bug in GCC 2.95.  GDB
fiddles a bit with the line number info trying to fix the breakage.
It's completely bogus, and should go since it messes up real-world
debugging with GCC 2.95 too.  Unfortunately doing so will mess up the
testsuite results when using GCC 2.95 :-(.

I'll try to get this fixed before the 6.2 release.  Thanks for giving
me a bit more ammunition for getting this change accepted by the rest
of the crowd.

Mark

Re: [RFC]: patch 1 for Sun C compiled target programs

[Daniel Jacobowitz]

On Fri, Jun 18, 2004 at 11:47:22PM +0200, Mark Kettenis wrote:
>    Date: Wed, 16 Jun 2004 19:57:32 +0200
>    From: Michael Mueller <m.mueller99@kay-mueller.de>
> 
>    Setting a breakpoint on a function name or on the first line of a 
>    function doesn't work for Sun C compiled target programs (32 and 64 
>    bit). I verified this against these compiler versions:
> 
>       Sun C 5.5 2003/03/12
>       Forte Developer 7 C 5.4 2002/03/09
>       Sun WorkShop 6 update 2 C 5.3 2001/05/15
>       Sun WorkShop 6 2000/04/07 C 5.1
> 
> Ah yes.  I knew about this.  Just forgotten all about it.  The funny
> code you're seeing is there to work around a bug in GCC 2.95.  GDB
> fiddles a bit with the line number info trying to fix the breakage.
> It's completely bogus, and should go since it messes up real-world
> debugging with GCC 2.95 too.  Unfortunately doing so will mess up the
> testsuite results when using GCC 2.95 :-(.
> 
> I'll try to get this fixed before the 6.2 release.  Thanks for giving
> me a bit more ammunition for getting this change accepted by the rest
> of the crowd.

Yeah, I recognized his symptoms also.  We have fixes for this issue in
both the stabs reader and the dwarf reader.  We could try tying them to
gcc_compiled (is it available by then?).  Or we could just give up and
rip them out.

-- 
Daniel Jacobowitz

Re: [RFC]: patch 1 for Sun C compiled target programs

[Michael Mueller]

Mark Kettenis wrote:
>    Date: Wed, 16 Jun 2004 19:57:32 +0200
>    From: Michael Mueller <m.mueller99@kay-mueller.de>
> 
>    Setting a breakpoint on a function name or on the first line of a 
>    function doesn't work for Sun C compiled target programs (32 and 64 
>    bit). I verified this against these compiler versions:
> 
>       Sun C 5.5 2003/03/12
>       Forte Developer 7 C 5.4 2002/03/09
>       Sun WorkShop 6 update 2 C 5.3 2001/05/15
>       Sun WorkShop 6 2000/04/07 C 5.1
> 
> Ah yes.  I knew about this.  Just forgotten all about it.  The funny
> code you're seeing is there to work around a bug in GCC 2.95.  GDB
> fiddles a bit with the line number info trying to fix the breakage.
> It's completely bogus, and should go since it messes up real-world
> debugging with GCC 2.95 too.  Unfortunately doing so will mess up the
> testsuite results when using GCC 2.95 :-(.

Can you give me some pointer to a mail thread or something describing this?

> 
> I'll try to get this fixed before the 6.2 release.  Thanks for giving
> me a bit more ammunition for getting this change accepted by the rest
> of the crowd.

Sounds promising. I filed PR gdb/1682 to remind you guys :-)

> 
> Mark
> 

Re: [RFC]: patch 1 for Sun C compiled target programs

[Mark Kettenis]

   Date: Mon, 21 Jun 2004 15:09:19 +0200
   From: Michael Mueller <m.mueller99@kay-mueller.de>

   > 
   > I'll try to get this fixed before the 6.2 release.  Thanks for giving
   > me a bit more ammunition for getting this change accepted by the rest
   > of the crowd.

   Sounds promising. I filed PR gdb/1682 to remind you guys :-)

Can you test the attached patch for me?  I don't have access to a
machine with a Sun compiler.  This patch should fix your problems
while keeping the current behaviour with GCC.

Thanks,

Mark


Index: dbxread.c
===================================================================
RCS file: /cvs/src/src/gdb/dbxread.c,v
retrieving revision 1.69
diff -u -p -r1.69 dbxread.c
--- dbxread.c 1 Jul 2004 20:25:53 -0000 1.69
+++ dbxread.c 10 Jul 2004 20:58:09 -0000
@@ -2659,6 +2659,7 @@ process_one_symbol (int type, int desc, 
   /* This holds the address of the start of a function, without the system
      peculiarities of function_start_offset.  */
   static CORE_ADDR last_function_start;
+  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
@@ -2736,6 +2737,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 +2930,12 @@ 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.  */
       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: [RFC]: patch 1 for Sun C compiled target programs

[Michael Mueller]

Mark Kettenis wrote:
>    Date: Mon, 21 Jun 2004 15:09:19 +0200
>    From: Michael Mueller <m.mueller99@kay-mueller.de>
> 
>    > 
>    > I'll try to get this fixed before the 6.2 release.  Thanks for giving
>    > me a bit more ammunition for getting this change accepted by the rest
>    > of the crowd.
> 
>    Sounds promising. I filed PR gdb/1682 to remind you guys :-)
> 
> Can you test the attached patch for me?  I don't have access to a
> machine with a Sun compiler.  This patch should fix your problems
> while keeping the current behaviour with GCC.

This works fine.

Michael