This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: SH breakpoint problem
Jonathan Larmour writes:
> 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)
Ok, I guess we'll (or I) have to cook up something similar to what mips does
for delay slots.
Elena
>
> 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