From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: gdb@sources.redhat.com Subject: SH breakpoint problem Date: Mon, 06 Aug 2001 19:45:00 -0000 Message-id: <3B6F5625.ADBD6F53@redhat.com> X-SW-Source: 2001-08/msg00036.html 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 : mov.l r14,@-r15 0x800b132 : mov r15,r14 0x800b134 : bra 0x800b134 0x800b136 : 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