From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Elena Zannoni Cc: Jonathan Larmour , gdb@sources.redhat.com Subject: Re: SH breakpoint problem Date: Thu, 09 Aug 2001 14:49:00 -0000 Message-id: <3B730568.6030003@cygnus.com> References: <3B6F5625.ADBD6F53@redhat.com> <15215.64646.329849.18396@krustylu.cygnus.com> <3B6FFC4F.FEE4535F@redhat.com> <15216.806.105796.615877@krustylu.cygnus.com> X-SW-Source: 2001-08/msg00096.html > 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