* Re: Remote debugging !
1999-04-01 0:00 Remote debugging ! Magdalena Sujecka
@ 1999-04-01 0:00 ` J.T. Conklin
0 siblings, 0 replies; 2+ messages in thread
From: J.T. Conklin @ 1999-04-01 0:00 UTC (permalink / raw)
To: Magdalena Sujecka; +Cc: gdb
>>>>> "Magdalena" == Magdalena Sujecka <maggee@ask.eti.pg.gda.pl> writes:
Magdalena> Hi everybody ! I would like to ask if somebody can help
Magdalena> (direct to information) about the remote option. I have
Magdalena> read the Stallman's guide and know that there are stubs for
Magdalena> special architecture (I need it for Sparc and i386). I also
Magdalena> know that I have to write extra functions like :
Magdalena> getDebugChar, putDebugChar, and also (and they bother me)
Magdalena> flush_i_cache, memset, exceptionHandler.
Magdalena> How should they look ? How can I write exceptionHandler() ?
Magdalena> I appreciate every piece of help.
I agree that the documentation for using the remote protocol, and the
sample stubs is somewhat lacking. I've thought about allocating some
time to improve this, but I've never got around to it.
The first thing you must remember is that the stubs provided with GDB
are samples. Feel free to customize them for your application, or if
necesary, rewrite them completely. For example, the stub embedded in
our products is nothing like the stubs provided in the distribution.
Of the functions you provide, getDebugChar() and putDebugChar() are
simply the mechanism the stub uses for transmitting and receiving the
the characters in the debug protocol. Any bi-directional channel is
acceptable. Whenever possible, I use a RS-232 serial channel as that
provides a lot of flexibility. A simple ???DebugChar() implementation
might just frob UART registers.
A flush_i_cache() function is needed on processors that don't have a
built-in cache invalidation mechanism. Otherwise, when the stub
writes memory under the control of GDB (for example, to insert a
breakpoint instruction) the instruction cache will contain invalid
data. This is processor dependent --- I'd probably implement it with
an inline assembly sequence containing the appropriate cashe flush
instruction.
The memset() function is needed by the sample SPARC stub because it
does not support the floating point registers (it simply clears the
memory region used for fp registers in the fetch registers command).
This is memset() with the standard ISO syntax & semantics.
The stub also calls strcpy() and strlen(), even though these functions
may be present in your target run time environment, it makes sense to
provide local implementations of these functions in your stub (most of
the sample stubs don't do this yet). The problem is that it is not
uncommon for users to set breakpoints on the mem* and str* functions,
and bad things will happen if the stub hits a breakpoint insn within
the exception handler.
The exceptionHandler() function is used to install the handler in the
processor's exception vector table. In our case, the vector table is
predefined, and we don't have to insert anything (the sample sh-stub
does this (although I kind of wish it didn't, IMO the sample stubs
should be more similar than different)). In another project I was
involved in, I simply copied the address of the handlers into the
table. This is going to depend on your target system.
--jtc
--
J.T. Conklin
RedBack Networks
^ permalink raw reply [flat|nested] 2+ messages in thread