SH breakpoint problem

[Andrew Cagney]

> Maybe I didn't quite understand what was meant to happen then. In the case
> of:
> 
> 1: {
> 2: for (;;);
> 3: }
> 
> where is the compiler meant to mark the end of the first source line in the
> debug info? You are saying it is 1, not 2 as I previously had been
> assuming.


Ignore the source, worry about the instruction stream.  Say the 
generated code looks like:

	foo:
(a) 
	move sp to fp
(b) 
1 
jmp b1
(c) 
	nop
(d) 
	return

The function's source-and-line is at (a), the start of the real code is 
at (b).  If the frame (move sp to fp) were to be omitted, then both 
would be at (b). So refering to your code there should be:

	1(a)
	2(b)
	3(d) (if you're lucky)

If the debug info for 2 is ending up on (c) then, yes, I really think 
things in GCC are wrong.

Compare it to the equivalent MIPS code.


>> o       The SH has delay slots and the subsequent
>> features.


_Features_ not bugs :-)


> So this bug _would_ be revealed if we set a breakpoint on line 2 above,
> right?


No, a breakpoint at 2 should end up on (b).


>> 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).
> 
> 
> So which source line _should_ the delay slot be associated with in the
> above example, if GCC is being nasty?


In the above example, it shouldn't.


>> Any way, the first problem is handed by fixing GCC  [:-)] 
> 
> 
> And I know even less about GCC than GDB. Oh dear.
> 
> 
>> 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)
> 
> 
> We've been doing both on our target.
> 
> 
>> 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
> 
> 
> Yuck, but I suppose it's possible. The implication of what you are saying
> is that it is up to the target to detect that the trap occured in a delay
> slot, and return the address of the delay slot instead of the reported
> address at the time of the exception. Right?


Possibly.  I think you're better off documenting this as a ``feature''. 
  If the user does this then they get what they deserve :-)

FWIW, things get quickly messy here.  Due to a bad case of history, both 
GDB and the remote protocol confuse the hardware program-counter with 
the more abstract stop/resume-address.  Eg, given:

	a:	jump foo
	b:	nop
		...
	foo:	

and a breakpoint on *b, then an architecture might represent/implement 
this in several different ways.  SPARC has:

	PC = b
	NPC = foo

a second target could have:

	PC = a
	status register indicates a delay slot implying PC is really B

(From memory this is what the MIPS does, restart after a breakpoint in a 
delay slot and you resume at the branch instruction)

In the case of the latter, you'd need to pretend that the PC is really 
at B and return that XOR have GDB modified to notice this case and have 
read_pc() return B.  Only, then you probably find that $pc has different 
values in different contexts (vis $fp on ARM).

Sigh

	Andrew