From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jonathan Larmour <jlarmour@redhat.com>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Elena Zannoni <ezannoni@cygnus.com>, gdb@sources.redhat.com
Subject: Re: SH breakpoint problem
Date: Thu, 09 Aug 2001 16:52:00 -0000
Message-id: <3B731D31.D2C2B57F@redhat.com>
References: <3B6F5625.ADBD6F53@redhat.com> <15215.64646.329849.18396@krustylu.cygnus.com> <3B6FFC4F.FEE4535F@redhat.com> <15216.806.105796.615877@krustylu.cygnus.com> <3B730568.6030003@cygnus.com>
X-SW-Source: 2001-08/msg00100.html

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