Re: SH breakpoint problem

[Jonathan Larmour <jlarmour at redhat dot com>]

Andrew Cagney wrote:
> 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.

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.

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

So this bug _would_ be revealed if we set a breakpoint on line 2 above,
right?
 
> 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?
 
> 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?

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