This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> "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