From mboxrd@z Thu Jan  1 00:00:00 1970
From: Elena Zannoni <ezannoni@cygnus.com>
To: Jonathan Larmour <jlarmour@redhat.com>
Cc: gdb@sources.redhat.com
Subject: Re: SH breakpoint problem
Date: Tue, 07 Aug 2001 07:26:00 -0000
Message-id: <15215.64646.329849.18396@krustylu.cygnus.com>
References: <3B6F5625.ADBD6F53@redhat.com>
X-SW-Source: 2001-08/msg00040.html

Jonathan Larmour writes:
 > I've been sanity checking both the GCC 3.0.1 candidate and the GDB 5.1
 > candidate, and I've found an issue on the SH, which I'm debugging remotely.
 > Setting a breakpoint on this simple function:
 > 
 > void
 > cyg_test_exit(void)
 > {
 >     for(;;);
 > }
 > 
 > fails - it reports a SIGILL. I believe this is probably a watchdog timer.
 > The problem is that, given the disassembly:
 > 
 > Dump of assembler code for function cyg_test_exit:
 > 0x800b130 <cyg_test_exit>:	mov.l	r14,@-r15
 > 0x800b132 <cyg_test_exit+2>:	mov	r15,r14
 > 0x800b134 <cyg_test_exit+4>:	bra	0x800b134 <cyg_test_exit+4>
 > 0x800b136 <cyg_test_exit+6>:	nop	
 > 
 > GDB sets the breakpoint at 0x800b136, rather than 0x800b134. Tracing
 > through GDB, I found after_prologue() in sh-tdep.c does:
 > 
 >   /* Get the line associated with FUNC_ADDR.  */
 >   sal = find_pc_line (func_addr, 0);
 > 
 >   /* There are only two cases to consider.  First, the end of the source
 > line
 >      is within the function bounds.  In that case we return the end of the
 >      source line.  Second is the end of the source line extends beyond the
 >      bounds of the current function.  We need to use the slow code to
 >      examine instructions in that case.  */
 >   if (sal.end < func_end)
 >     return sal.end;
 > 
 > The problem is, I believe, that the debug info is probably right and the
 > end of the source line is indeed 0x800b136 (as is returned from
 > find_pc_line) since the nop is in a delay slot, but it is mistaken to
 > assume that is where the breakpoint should be set.
 > 
 > But I don't know what way I should try to fix it. Matching instructions
 > with delay slots like branches explicitly by reading from the target is my
 > first thought but it seems awfully wasteful, and I'm sure there is received
 > knowledge on this subject. So, what is it :-).

I should know, but I don't (I am the gdb sh person). :-(
What does gdb do with the same program against the simulator?

Elena