This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gdb port to or1k


>>>>> "Marko" == Marko Mlinar <Marko.Mlinar@campus.fri.uni-lj.si> writes:
Marko> I've seen JTAG driver or BDM driver.  I am aware that JTAG
Marko> driver is very slow.  We are hoping we can get troughput of
Marko> 75kB/sec (with some extra logic), and 15kB/sec without any
Marko> logic.  Do you think that is enough?

I have found that latency tends to matter a great deal more in a
typical debugging session than bandwidth.  

For example, think of stepping a single line of code.  The debugger
determines the the range of code represented by the line, and then
issues a step instruction command.  Then it waits until the target
responds with a exception or trap.  The debugger then must fetch the
the program counter to determine whether the step has taken the PC
out of range.  If not it repeats the processes.

As you can see, the commands and responses themselves aren't too long.
But if there is significiant communications overhead, it adds up fast.
And that is all with relatively high level commands like "step insn".
If instead you must fetch the processor control word, or in a trace
mode bit, and the store it; or if you fetch the word at the memory
location after the PC and then store a trap/breakpoint instruction;
it gets that much worse.

Even with GDB's remote protocol which had relatively high level commands, 
I recently added a command for "step over range" which would single step
until the PC goes outside the address range specified in the command.  I
did this just to improve the interactive performance of GDB.

Where bandwith matters, is bulk transfers.  This usually occurs when
fetching or storing the whole register set, and when downloading code.

I don't know enough about your interface and processor whether you
will be able to fetch and store single registers, or whether you'll
have to do the whole set.  In most cases, GDB only needs the PC and
stack and frame pointers, after a trap to determine "where it is".
It's user commands after that which may require more of the registers
to be fetched.  

But even if the whole set has to be fetched or stored, at 75kB/s, a
~512B (32 64-bit int regs, 32 64-bit fp regs, plus a handful of config
regs) should be acceptable assuming low communcation overhead.  But at
15kB/s, communication overhead will have to be low, since we're already
at 1/3 the 0.1 second threshold for interactive response.

With a JTAG like interface, I suspect you will want the ability to
download code.  At 75kB/s, you can download a decent size application
in a minute.  But for very large applications, I'd probably use the
interface to download a secondary boot program that would load the
"real" program over a faster medium (ethernet?)

        --jtc

-- 
J.T. Conklin
RedBack Networks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]