[RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present

[RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present

[Fred Fish]

For the following test case:

  sub1 ()
  {
    printf ("In sub1\n");
  }
  
  sub2 ()
  {
    printf ("In sub2\n");
  }
  
  main ()
  {
    sub1 ();
    sub2 ();
  }

sh-elf-gcc with -O2 will schedule the code to call sub1 into the
prologue of main.  If the code is compiled WITHOUT debug info, the
prologue scanner in gdb will not stop when it sees the jsr and will
eventually return a pc somewhere after the jsr.  For example:

  (gdb) br main
  Breakpoint 1 at 0x1162
  (gdb) x/8i main
  0x1158 <main>:	mov.l	r14,@-r15
  0x115a <main+2>:	mov.l	0x116c <main+20>,r0	! 0x1120
  0x115c <main+4>:	sts.l	pr,@-r15
  0x115e <main+6>:	jsr	@r0
  0x1160 <main+8>:	mov	r15,r14
* 0x1162 <main+10>:	mov.l	0x1170 <main+24>,r1	! 0x113c
  0x1164 <main+12>:	mov	r14,r15
  0x1166 <main+14>:	lds.l	@r15+,pr

Note that the breakpoint on main() gets set well after the jsr.  When
you set breakpoints at sub1 and sub2 and run the program, you get:

  (gdb) run
  Starting program: /links1/build/sourceware/gdb/T-sh-elf/gdb/g 
  Breakpoint 2, 0x00001128 in sub1 ()
  (gdb) c
  Continuing.
  In sub1
  Breakpoint 1, 0x00001162 in main ()
  (gdb) c
  Continuing.
  Breakpoint 3, 0x00001144 in sub2 ()
  (gdb) c
  Continuing.
  In sub2
  Program exited with code 012.

which is very confusing because it appears that sub1 is called before main!

With the attached patch, the prologue scanner returns the pc of the
jsr instruction, allowing the breakpoint at main to be hit before the
breakpoint at sub1:

  (gdb) br main
  Breakpoint 1 at 0x115e
  (gdb) x/8i main
  0x1158 <main>:	mov.l	r14,@-r15
  0x115a <main+2>:	mov.l	0x116c <main+20>,r0	! 0x1120
  0x115c <main+4>:	sts.l	pr,@-r15
* 0x115e <main+6>:	jsr	@r0
  0x1160 <main+8>:	mov	r15,r14
  0x1162 <main+10>:	mov.l	0x1170 <main+24>,r1	! 0x113c
  0x1164 <main+12>:	mov	r14,r15
  0x1166 <main+14>:	lds.l	@r15+,pr
  (gdb) br sub1
  Breakpoint 2 at 0x1128
  (gdb) br sub2
  Breakpoint 3 at 0x1144
  (gdb) run
  Starting program: /links1/build/sourceware/gdb/T-sh-elf/gdb/g 
  Breakpoint 1, 0x0000115e in main ()
  (gdb) c
  Continuing.
  Breakpoint 2, 0x00001128 in sub1 ()
  (gdb) c
  Continuing.
  In sub1
  Breakpoint 3, 0x00001144 in sub2 ()
  (gdb) c
  Continuing.
  In sub2
  Program exited with code 012.

It's also useful to note where the breakpoint gets set if you recompile to generate
debugging information:

  (gdb) br main
  Breakpoint 1 at 0x115a: file g.c, line 13.
  (gdb) x/8i main
  0x1158 <main>:          mov.l   r14,@-r15
  0x115a <main+2>:        mov.l   0x116c <main+20>,r0     ! 0x1120
  0x115c <main+4>:        sts.l   pr,@-r15
  0x115e <main+6>:        jsr     @r0
  0x1160 <main+8>:        mov     r15,r14
  0x1162 <main+10>:       mov.l   0x1170 <main+24>,r1     ! 0x113c
  0x1164 <main+12>:       mov     r14,r15
  0x1166 <main+14>:       lds.l   @r15+,pr

This patch causes no regressions in the gdb testsuite.  Anyone see any
issues with installing it?  :-)

-Fred


2004-02-12  Fred Fish  <fnf@redhat.com>

	* sh-tdep.c (IS_JSR): New macro.
	(sh_analyze_prologue): Use IS_JSR to terminate prologue scan.

Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.158
diff -c -p -r1.158 sh-tdep.c
*** sh-tdep.c	11 Feb 2004 15:40:28 -0000	1.158
--- sh-tdep.c	12 Feb 2004 21:16:39 -0000
*************** sh_breakpoint_from_pc (CORE_ADDR *pcptr,
*** 333,338 ****
--- 333,341 ----
  #define GET_SOURCE_REG(x)  	(((x) >> 4) & 0xf)
  #define GET_TARGET_REG(x)  	(((x) >> 8) & 0xf)
  
+ /* JSR @Rm         0100mmmm00001011 */
+ #define IS_JSR(x)		(((x) & 0xf0ff) == 0x400b)
+ 
  /* STS.L PR,@-r15  0100111100100010
     r15-4-->r15, PR-->(r15) */
  #define IS_STS(x)  		((x) == 0x4f22)
*************** sh_analyze_prologue (CORE_ADDR pc, CORE_
*** 530,535 ****
--- 533,552 ----
  	      else
  		break;
  	    }
+ 	  break;
+ 	}
+       else if (IS_JSR (inst))
+ 	{
+ 	  /* We have found a jsr that has been scheduled into the prologue.
+ 	     If we continue the scan and return a pc someplace after this,
+ 	     then setting a breakpoint on this function will cause it to
+ 	     appear to be called after the function it is calling via the
+ 	     jsr, which will be very confusing.  Most likely the next
+ 	     instruction is going to be IS_MOV_SP_FP in the delay slot.  If
+ 	     so, note that before returning the current pc. */
+ 	  inst = read_memory_integer (pc + 2, 2);
+ 	  if (IS_MOV_SP_FP (inst))
+ 	    cache->uses_fp = 1;
  	  break;
  	}
  #if 0				/* This used to just stop when it found an instruction that

Re: [RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present

[Elena Zannoni]

Fred Fish writes:
 > For the following test case:
 > 
 >   sub1 ()
 >   {
 >     printf ("In sub1\n");
 >   }
 >   
 >   sub2 ()
 >   {
 >     printf ("In sub2\n");
 >   }
 >   
 >   main ()
 >   {
 >     sub1 ();
 >     sub2 ();
 >   }
 > 


Is this in our testsuite? (it looks familiar) If not could it be added? 

 > sh-elf-gcc with -O2 will schedule the code to call sub1 into the
 > prologue of main.  If the code is compiled WITHOUT debug info, the
 > prologue scanner in gdb will not stop when it sees the jsr and will
 > eventually return a pc somewhere after the jsr.  For example:
 > 
 >   (gdb) br main
 >   Breakpoint 1 at 0x1162
 >   (gdb) x/8i main
 >   0x1158 <main>:	mov.l	r14,@-r15
 >   0x115a <main+2>:	mov.l	0x116c <main+20>,r0	! 0x1120
 >   0x115c <main+4>:	sts.l	pr,@-r15
 >   0x115e <main+6>:	jsr	@r0
 >   0x1160 <main+8>:	mov	r15,r14
 > * 0x1162 <main+10>:	mov.l	0x1170 <main+24>,r1	! 0x113c
 >   0x1164 <main+12>:	mov	r14,r15
 >   0x1166 <main+14>:	lds.l	@r15+,pr
 > 
 > Note that the breakpoint on main() gets set well after the jsr.  When
 > you set breakpoints at sub1 and sub2 and run the program, you get:
 > 
 >   (gdb) run
 >   Starting program: /links1/build/sourceware/gdb/T-sh-elf/gdb/g 
 >   Breakpoint 2, 0x00001128 in sub1 ()
 >   (gdb) c
 >   Continuing.
 >   In sub1
 >   Breakpoint 1, 0x00001162 in main ()
 >   (gdb) c
 >   Continuing.
 >   Breakpoint 3, 0x00001144 in sub2 ()
 >   (gdb) c
 >   Continuing.
 >   In sub2
 >   Program exited with code 012.
 > 
 > which is very confusing because it appears that sub1 is called before main!
 > 
 > With the attached patch, the prologue scanner returns the pc of the
 > jsr instruction, allowing the breakpoint at main to be hit before the
 > breakpoint at sub1:
 > 

OK.

Re: [RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present

[Fred Fish]

On Monday 16 February 2004 08:42, Elena Zannoni wrote:
> Is this in our testsuite? (it looks familiar) If not could it be added?

It is not in there directly, but was found as a side effect of
gdb1291.  I'll go ahead and report it as a distinct gdb bug to get a
bug number and then add a test in gdb.arch.

> > With the attached patch, the prologue scanner returns the pc of the
> > jsr instruction, allowing the breakpoint at main to be hit before the
> > breakpoint at sub1:
>
> OK.

I'll post an updated patch when I have a test ready to go with it, and
then check them in.

-Fred

Re: [RFA] Handle sh-elf-gcc scheduling code into a prologue when no debug info present

[Fred Fish]

On Monday 16 February 2004 11:14, Fred Fish wrote:
> I'll post an updated patch when I have a test ready to go with it, and
> then check them in.

Committed.

Here is the pair of patches, one to the testsuite and one to the main
gdb directory.

-Fred

############################################################################

2004-02-19  Fred Fish  <fnf@redhat.com>

	New testcase for PR breakpoint/1558.
	* gdb.arch/gdb1558.exp: New file.
	* gdb.arch/gdb1558.c: New file.

Index: testsuite/gdb.arch/gdb1558.c
===================================================================
RCS file: testsuite/gdb.arch/gdb1558.c
diff -N testsuite/gdb.arch/gdb1558.c
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/gdb.arch/gdb1558.c	19 Feb 2004 22:49:44 -0000
***************
*** 0 ****
--- 1,36 ----
+ /* Copyright 2004 Free Software Foundation, Inc.
+  
+    This program is free software; you can redistribute it and/or modify
+    it under the terms of the GNU General Public License as published by
+    the Free Software Foundation; either version 2 of the License, or
+    (at your option) any later version.
+  
+    This program is distributed in the hope that it will be useful,
+    but WITHOUT ANY WARRANTY; without even the implied warranty of
+    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+    GNU General Public License for more details.
+  
+    You should have received a copy of the GNU General Public License
+    along with this program; if not, write to the Free Software
+    Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+  
+    Please email any bugs, comments, and/or additions to this file to:
+    bug-gdb@gnu.org
+  
+    This file is part of the gdb testsuite.  */
+ 
+ sub1 ()
+ {
+   printf ("In sub1\n");
+ }
+   
+ sub2 ()
+ {
+   printf ("In sub2\n");
+ }
+   
+ main ()
+ {
+   sub1 ();
+   sub2 ();
+ }
Index: testsuite/gdb.arch/gdb1558.exp
===================================================================
RCS file: testsuite/gdb.arch/gdb1558.exp
diff -N testsuite/gdb.arch/gdb1558.exp
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- testsuite/gdb.arch/gdb1558.exp	19 Feb 2004 22:49:44 -0000
***************
*** 0 ****
--- 1,72 ----
+ # Copyright 2004 Free Software Foundation, Inc.
+ 
+ # This program is free software; you can redistribute it and/or modify
+ # it under the terms of the GNU General Public License as published by
+ # the Free Software Foundation; either version 2 of the License, or
+ # (at your option) any later version.
+ #
+ # This program is distributed in the hope that it will be useful,
+ # but WITHOUT ANY WARRANTY; without even the implied warranty of
+ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ # GNU General Public License for more details.
+ #
+ # You should have received a copy of the GNU General Public License
+ # along with this program; if not, write to the Free Software
+ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+ 
+ # Please email any bugs, comments, and/or additions to this file to:
+ # bug-gdb@gnu.org
+ 
+ # This file is part of the gdb testsuite.
+ 
+ # Tests for PR:1558.  Hits breakpoint at main after function called
+ # from main.
+ 
+ if $tracelevel {
+     strace $tracelevel
+ }
+ 
+ set prms_id 0
+ set bug_id 0
+ 
+ if ![istarget "sh-*-*"] then {
+     verbose "Skipping SH breakpoint test."
+     return
+ }
+ 
+ set testfile "gdb1558"
+ set srcfile ${testfile}.c
+ set binfile ${objdir}/${subdir}/${testfile}
+ # Note we have to compile WITH optimization and WITHOUT debugging information to expose the bug.
+ if { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {"additional_flags=-O2"}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+ }
+ 
+ gdb_exit
+ gdb_start
+ gdb_reinitialize_dir $srcdir/$subdir
+ gdb_load ${binfile}
+ 
+ gdb_test "b main" "Breakpoint 1.*" "set breakpoint at main"
+ gdb_test "b sub1" "Breakpoint 2.*" "set breakpoint at sub1"
+ gdb_test "b sub2" "Breakpoint 3.*" "set breakpoint at sub2"
+ 
+ # We can't use "runto_main" because that is exactly the problem
+ # we are trying to detect, stopping somewhere before main.
+ 
+ gdb_run_cmd
+ 
+ gdb_expect 30 {
+     -re "Breakpoint 1.*main .*$gdb_prompt $" {
+ 	pass "Hits breakpoint at main after function called from main"
+     }
+     -re "Breakpoint 2.*sub1 .*$gdb_prompt $" {
+ 	kfail "gdb/1558" "Hits breakpoint at main after function called from main"
+     }
+     -re "$gdb_prompt $" { 
+ 	fail "Hits breakpoint at main after function called from main"
+     }
+     timeout { 
+ 	fail "Hits breakpoint at main after function called from main (timeout)"
+     }
+ }

############################################################################

2004-02-19  Fred Fish  <fnf@redhat.com>

	Fix for PR breakpoint/1558.
	* sh-tdep.c (IS_JSR): New macro.
	(sh_analyze_prologue): Use IS_JSR to terminate prologue scan.

Index: sh-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sh-tdep.c,v
retrieving revision 1.163
diff -c -p -r1.163 sh-tdep.c
*** sh-tdep.c	17 Feb 2004 16:04:19 -0000	1.163
--- sh-tdep.c	19 Feb 2004 22:49:39 -0000
*************** sh_breakpoint_from_pc (CORE_ADDR *pcptr,
*** 311,316 ****
--- 311,319 ----
  #define GET_SOURCE_REG(x)  	(((x) >> 4) & 0xf)
  #define GET_TARGET_REG(x)  	(((x) >> 8) & 0xf)
  
+ /* JSR @Rm         0100mmmm00001011 */
+ #define IS_JSR(x)		(((x) & 0xf0ff) == 0x400b)
+ 
  /* STS.L PR,@-r15  0100111100100010
     r15-4-->r15, PR-->(r15) */
  #define IS_STS(x)  		((x) == 0x4f22)
*************** sh_analyze_prologue (CORE_ADDR pc, CORE_
*** 508,513 ****
--- 511,530 ----
  	      else
  		break;
  	    }
+ 	  break;
+ 	}
+       else if (IS_JSR (inst))
+ 	{
+ 	  /* We have found a jsr that has been scheduled into the prologue.
+ 	     If we continue the scan and return a pc someplace after this,
+ 	     then setting a breakpoint on this function will cause it to
+ 	     appear to be called after the function it is calling via the
+ 	     jsr, which will be very confusing.  Most likely the next
+ 	     instruction is going to be IS_MOV_SP_FP in the delay slot.  If
+ 	     so, note that before returning the current pc. */
+ 	  inst = read_memory_integer (pc + 2, 2);
+ 	  if (IS_MOV_SP_FP (inst))
+ 	    cache->uses_fp = 1;
  	  break;
  	}
  #if 0				/* This used to just stop when it found an instruction that

############################################################################