Re: SH breakpoint problem

[Andrew Cagney <ac131313@cygnus.com>]

> Ok, I guess we'll (or I) have to cook up something similar to what mips does
> for delay slots.


(Or TiC80 - er oops, deleted that :-)

I think there are two bugs:

	o	GCC is marking the end of the prologue
		and the start of the code proper
		with an instruction sitting in a delay slot.

		Put simply OUTCH!

		I'd consider that a GCC bug.  Especially
		if it was compiled without -O.

	o	The SH has delay slots and the subsequent
		features.

The delay slot problem tends to only occure when a user explicitly 
inserts a breakpoint at a specific address (or GCC gets nasty and starts 
outputting source-and-line info that contains delay slots).

Any way, the first problem is handed by fixing GCC :-)

The second problem is more interesting, targets handle delay slots by:

	o	have code such as software
		instruction-step detect and skip
		both the jmp and the delay slot

	o	have the target when doing hardware
		single step skip both (I suspect
		the SH does this)

	o	have the hardware provide sufficient
		information to allow GDB to detect
		a delay-slot breakpoint.

If either of the first two options are taken (they are both reasonable!) 
then it is a ``the user is always right'' situtation when they enter:

	(gdb) break *address_of_delay_slot

This is because, in general, GDB can't tell if what looks like and 
smells like a delay slot really is.  GDB just has to assume that the 
USER (who is always right and in this case, since they are using 
assembler level features, must understand the ISA's delay slot :-) 
really is trying to debug something like:

	jump bar
	nop
	.....
	jump foo
   bar:	move r1 to r2

enjoy,
	Andrew