From mboxrd@z Thu Jan 1 00:00:00 1970 From: jtc@redback.com (J.T. Conklin) To: malar kavi Cc: gdb@sourceware.cygnus.com Subject: Re: remote debugging Date: Thu, 25 Jan 2001 11:46:00 -0000 Message-id: <5mlmrzmn3t.fsf@jtc.redback.com> References: <20010125132711.2294.qmail@web5504.mail.yahoo.com> X-SW-Source: 2001-01/msg00176.html >>>>> "malar" == malar kavi 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