Re: SH breakpoint problem

[Kevin Buettner <kevinb@cygnus.com>]

On Aug 7,  3:44am, Jonathan Larmour wrote:

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

My opinion is that gdb should use the information obtained from
find_pc_line() only to refine the limit searched by the prologue
scanner.  The prologue scanner needs to be taught that it must
never scan past an instruction which modifies the flow of control
(i.e, branch or call instructions).

Kevin