Re: remote debugging

[jtc at redback dot com (J.T. Conklin)]

>>>>> "malar" == malar kavi <malarkavi@yahoo.com> writes:
malar>    There are some subroutines like
malar> getDebugChar,putDebugChar,flash_i_cache,memset,
malar> exceptionhandler used in i386-stub.c.How can i write
malar> these subroutines and link with the program?After
malar> linking how should i start the program in the target
malar> machine?How should i establish serial communication
malar> with the target machine?
malar>        I will be really grateful if anybody is able
malar> to get me out of these problems.
malar>             Thanking u in advance.

The getDebugChar() and putDebugChar() functions are simple functions
that you have to supply that interface with some i/o device, usually
a serial port.  They don't have to be sophisticated.  On many of the
targets I've done this on, I've used polled I/O on UART registers.

For the i386-stub, you don't have to worry about flush_i_cache().  On
some processors, you have to flush the instruction (and sometimes the
data) cache before resuming program execution.

Again, memset() is not needed for the i386-stub.  If you were using
one of the sparc stubs (sparc-stub.c or sparclet-stub.c), you would
need to provide a memset() which conforms to Standard (ANSI/ISO) C.
This is actually a bug in those stubs.  They should provide their 
own static implementation, otherwise the user can't put breakpoints
at memset() to find bugs in their own system.

exceptionHandler() is used to install the exception handlers within
the stub in the processor's exception handler table.  In many of my
targets I have a static exception handler table, so I don't install
the exception handlers dynamically.  You are the best person to know
how you want to do this.  The way you allready install exception and/
or interrupt handlers will probably determine how you do the same for
the debugger stub.

The easiest way to establish connection is to add a call to
breakpoint() as soon as your target has initialized enough to do so.
In other words, after you've initialized the hardware to the point 
where your debug channel is up and after you've installed the stub's
exception handler.  When your program hits the breakpoint() call, it
will enter the stub's handle_exception loop.  At that point, you 
simply need to connect to the debugger ('target remote /dev/ttyXX').

Once you've managed that, you might want to make things a little more
sophisticated.  For example, if you had an interrupt driven i/o driver
you could set things up so the stub was entered as soon as a character 
is received.  I recommend that you get a basic polled i/o mechanism 
working first though.

        --jtc

-- 
J.T. Conklin
RedBack Networks