gdb2ndi translates the gdb remote debugger protocol to the netware server remote debugger protocol (ndi).
The nlm-name (from the servers point of view) and the ip-address assigned to RDedbug/DBNet (or the serial port) has to be specified, the other parameters are optional
Examples:
Load the nlm sys:test/hello.nlm, connect to RDebug/DBNet at 192.168.126.200 and wait for a gdb connection on port 5555
or Serial:
Load the nlm sys:test/hello.nlm, connect to RDebug/DBNet via Serial Port com1 at 115200 baud and wait for a gdb connection on port 5555
gdb2ndi supports the following gdb remote commands:
g read registers
c
continue
c address
continue at address
s step
s address step from address
m address,length read memory, a maximum length of 1024 bytes per call is supported. gdb2ndi implements a simple cache, it will try to read 256 bytes from ndi and buffer that. (Because gdb always reads only one byte). The cache will be flushed by c,s and M. Cache can be disabled with the -c switch.
M address,length write memory, a maximum length of 1024 bytes per call is supported
Z0,z0 set/clear breakpont
Z2,z2 set/clear Hardware write watchpoint
Z3,z3 set/clear Hardware read watchpoint. Because i dont know if a read watchpoint works, z3 sets a read/write watchpoint
Z4,z4 set/clear Hardware read/write watchpoint
? Indicate the reason the target halted
qThreadExtraInfo Returns information for the specified thread
qOffsets Returns Text, Data and Bss address of the loaded nlm
qfThreadInfo Threadlist first (a maximum number of 16 threads will be delivered per call)
qsThreadInfo Threadlist next (a maximum number of 16 threads will be delivered per call)
qC return current thread
Hc set thread (Continue/Step). Not supported but gdb2ndi returns OK
Hg set thread (Other operations). Not supported but gdb2ndi returns OK
Gdb does not work with thread numbers greater 0x7ffffff and (at least on my netware 6 testserver) all netware thread ids are greater. gdb2nlm reports threads beginning with 1 to gdb. These numbers are unique in a gdb session, newly created threads will be reported with a number greater than the last used one.
Enter the internal Debugger
Enter the debugger by pressing shift shift alt esc.
Start serial
Enter rdebug serial baud=115200 in case the server responds with Serial Port Address error, try rdebug serial port=3f8 baud=115200 for com1 or rdebug serial port=2f8 baud=115200 for com2
At least netware6.5, 6.0 and 5.1 provides debug output for rdebug, try rdebug help
The parameters after rdebug have to be provided only once. The second time you can enter and it will start with the same parameters. You can also save the parameters in the file rdebug.cfg (has to be on the dos partition in the same path as server.exe)
Please note that the serial communication will not work correct when rdebug debug or rdebug low is active. This is because the server will flush the input buffer after processing a packet. I assume that the screen output will take some time so that in case two packets will be send, the start of the second packet will be lost. gdb2ndi will retry the command but that makes the communication very slow.
I have tested serial communication with netware 6.0 sp2 and netware 5.1 sp5.
Start over Ethernet
The netware internal debugger provides support for ne2000 and compatible isa cards only. Other cards can be used with dbnet5/dbnet6.nlm.
Enter the internal debugger and start rdebug with rdebug ne2000 ip=192.168.1.199 port=320
Replace the ip with one address of your subnet and the port with the i/o port your ne2000 is configured.
I have tested ethernet communication with netware 6 sp2 and netware 4.11. For netware 4.11 you have to load rdebug.nlm, only netware 5 and up has internal support for ne2000 cards. For other cards DBNET5/DBNET6.NLM has to be used. DBNETx.NLM has to be loaded with the parameter /ndi and the command would be "rdebug dbnet".
Netware 6.5 sp2 and sp3 beta will not work the standard way because of bugs in the internal debugger. gdb2ndi provides a workaround. You have to use the -a (attach) parameter and load the nlm manual via the load command at the server console. To do this automaticly (also with auto invoke of rdebug dbnet) you can load gdbhelp.nlm on the server and use the -t and -l switch in addition to -a. gdbhelp is a simple nlm that waits for a tcp connection on port 15001. I accepts a text with the value "EnterDebugger" and optional "EnterDebugger NLM=NlmToLoad". It will post "rdebug dbnet" to the internal debugger and invoke it. Next it will do a SYSTEM "load NlmToLoad". Because of that really simple nature, never load gdbhelp on a production server.
Lets assume we are using ethernet and the server has the ip 192.168.253.199. The nlm we want to debug is sys:test/hello.nlm. We will run gdb2ndi in a separate console to see what happens.
First start rdebug on the server so that the server will wait for incoming rdebug connections over ethernet.
start gdb2ndi
gdb2ndi --listen-port=12000 -d -d -D -D --nlm=sys:test/hello.nlm --server-ip=192.168.253.199
or with auto debugger invoke and autoload of the nlm with loaded gdbhelp.nlm:
gdb2ndi --listen-port=12000 -d -d -D -D --nlm=sys:test/hello.nlm --server-ip=192.168.253.199 --attach --auto-activate --auto-load
you will something like this:
All messages except first two and the last one will only be shown with activated debug options.
now you can start gdb (you need a version with netware support compiled in, see COMPILING GDB). I have named my version gdbnw.
Its simple, configure gdb with
and start make. Some gdb-versions will stop in the directory gdb/nlm with errors (GDBSERVE does not support this target). We dont need this, it is the old gdbserver.nlm. In that case, edit the file gdb/configure.tgt, search for nlm and remove nlm in all configdirs.
gdb/Makefile.in needs a similar change, search for nlm: and remove the nlm subdir in the next line
now do configure --target=i386-pc-netware and make. I have compiled gdb for netware for redhat linux and cygwin win32.
Currently i dont know the structure for the floating point registers returned by ndi. st0 to st7 are sent to gdb and they are shown in gdb exactly like the RF command on the server but the rest is missing.