hardware support for gdb?

[Vijay Kamarshi]

Bill,

Thanks for your reply.  I will look at your gdbstubs code shortly.

-Vijay

-----Original Message-----
From: gdb-owner@sources.redhat.com
[mailto:gdb-owner@sources.redhat.com]On Behalf Of Bill Gatliff
Sent: Wednesday, February 18, 2004 6:25 AM
To: Vijay Kamarshi
Cc: gdb@sources.redhat.com
Subject: Re: hardware support for gdb?


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