Re: SH breakpoint problem

[Jonathan Larmour <jlarmour@redhat.com>]

Elena Zannoni wrote:
> 
> 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?

It has the same failing:

(gdb) disass cyg_test_exit
Dump of assembler code for function cyg_test_exit:
0x10e4 <cyg_test_exit>:	mov.l	r14,@-r15
0x10e6 <cyg_test_exit+2>:	mov	r15,r14
0x10e8 <cyg_test_exit+4>:	bra	0x10e8 <cyg_test_exit+4>
0x10ea <cyg_test_exit+6>:	nop	
End of assembler dump.
(gdb) b cyg_test_exit
Breakpoint 1 at 0x10ea: file foo.c, line 3.
(gdb) run
Starting program: /export/pot/ecc-obj/sh/edk/foo 

Program received signal SIGTRAP, Trace/breakpoint trap.
0x000010e8 in cyg_test_exit () at foo.c:2
2	{
(gdb) 

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine