[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [openrisc] Patch: Reduced gdb<->target communication



On Tuesday 08 April 2003 04:29, Scott Furman wrote:
> I use the or32 version of gdb both with JTAG targets and serial targets
> (the latter target uses the GDB serial stubs support in eCos).  In the
> serial case, the debugger can be rather sluggish, especially when
> generating backtraces, due to the large amount of serial traffic
> generated.  The attached patch cures two shortcomings with the current
> code:
How is it working with serial port otherwise. As far as I understood from 
gdb'ers experiences serial target is too slow and somehow unusable.
Maybe for stubs it is ok.
Do you download the code through serial port also?
Do you have two separate cables connected to the board?


> *	When generating backtraces, the prologue of each function is
> scanned at least three times by architecture-independent code, e.g. to
> determine offsets of saved registers, identify frameless functions, etc.
> The new code in the attached patch adds straightforward caching of the
> information gleaned by or1k_scan_prologue() on a per-frame basis rather
> than storing it in global static variables.  (This benefits both JTAG
> and serial gdb targets, though the JTAG target runs fast enough that it
> is not particularly needed.)
> *	When the register set is dumped by the serial target, e.g. at
> any breakpoint or interrupt, the 32 vector/FP registers are included in
> the dump (each 8 bytes long), though they aren't implemented by the
> architecture.  The attached patch tells gdb that unimplemented registers
> have zero length in the dump, so that they are not sent/expected.  I
> don't believe this change has any effect on the JTAG target which uses
> its own protocol for register dumps.  (And I have been running with
> these patches for weeks, so I'm sure they haven't broken anything with
> the JTAG target).
I think these are ok.

Marko

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml