This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: SH breakpoint problem
> 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