Re: hardware support for gdb?

[Bill Gatliff <bgat at billgatliff dot com>]

Vijay:


> Do you see an advantage in *not* having GDB do the disassembly for single
> stepping across a branch instruction?

I don't think the code is any different, no matter where it's located.  
It's better to do it on the target for bandwidth reasons, but that's the 
only advantage I can think of offhand.

Well, that and the case where the stub is in ROM, and can't be 
bugfixed.  :^)

> I imagine, in the debug stub on remote target, you disassemble the branch
> instruction and place break instructions at the two possible code paths.
> When one of the code path hits, you copy back the original instructions to
> the two locations and continue.  Is this the way you implement it?  Or the
> other option would be to actually figure out which path would be taken and
> place one break instruction there.

You can look at my code, it's in the gdbstubs project on Sourceforge.

I'm disassembling on the remote target, determining where the branch 
will go (i.e. branch or not), and setting the break instruction at the 
destination.  I have considered many times setting two breakpoints so 
that I don't have to compute the destination, but during implementation 
I learned that computing a conditional branch destination is the hard 
part; the check to see if you're going there is usually just looking at 
a bit or two in the processor's status register, and is quite easy.

> If you are implementing instruction disassembly in your stubs, then you must
> have a way of telling the GDB host not to do this in the host.  Is this just
> done via the regular serial communication protocol?

That's the interesting question.  I've never seen gdb try to do the 
disassembly itself during instruction stepping, so I don't know how to 
turn it on or off!

> We are using a processor core that implements speculative branching.  I am
> wondering how I am going to get it to work right.

I bet it's a lot like the prefetching behavior on ARM7/9, which is that 
you don't even know it's going on unless you are directly manipulating 
the PC.  There are only a few places where I have to do that.

In processors like the SH that have a delay slot, I have simply decided 
that you can't stepi the delay slot instruction.  :^)


b.g.

--
Bill Gatliff
Public embedded GNU and embedded Linux training dates announced!
bgat@billgatliff.com