SH breakpoint problem

[Jonathan Larmour <jlarmour@redhat.com>]

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 :-).

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