文件列表:

246332\gdbstub-2.0.36\gdbinit (606, 1998-10-03)
246332\gdbstub-2.0.36\Install (4462, 1998-12-31)
246332\gdbstub-2.0.36\kfiles (55, 1998-10-03)
246332\gdbstub-2.0.36\Makefile (134, 1998-10-03)
246332\gdbstub-2.0.36\mk_tar (712, 1998-12-31)
246332\gdbstub-2.0.36\Remove (1452, 1998-12-31)
246332\gdbstub-2.0.36\version (7, 1998-10-03)
246332\gdbstub-2.0.36\stubs-2.0.tar (30720, 1998-10-03)
246332\gdbstub-2.0.36\stubs-2.1.tar (30720, 1998-10-03)
246332\gdbstub-2.0.36\gdbstub.c (3006, 1998-10-04)
246332\gdbstub-2.0.36\patches_ins.gdbstub.2.0 (5814, 1998-10-05)
246332\gdbstub-2.0.36\patches_rm.gdbstub.2.0 (5814, 1998-10-05)
246332\gdbstub-2.0.36\patches_ins.gdbstub.2.1 (5791, 1998-10-03)
246332\gdbstub-2.0.36\patches_rm.gdbstub.2.1 (5791, 1998-10-03)
246332\gdbstub-2.0.36\patches_ins.gdbstub.2.2 (5776, 1998-12-31)
246332\gdbstub-2.0.36\patches_rm.gdbstub.2.2 (5776, 1998-12-31)
246332\gdbstub-2.0.36\patches.gdbstub.2.0.24 (7349, 1998-10-04)
246332\gdbstub-2.0.36\patches.gdbstub.2.0.30 (6423, 1998-10-04)
246332\gdbstub-2.0.36 (0, 2011-02-18)
246332 (0, 2011-02-18)

This directory contains the components necessary to perform remote debugging of the Linux kernel using two machines and gdb. Advice ====== Before installing it is good to know that this installation procedure works best when applied to a kernel source tree that does not have a previous version of gdbstub installed in it. The "Remove" procedure that comes with this package will likely not succeed in removing an older version of the patch. This is not a problem since the older versions run just fine and do not need to be updated. If you have an older version already installed, see the note at the end of this file for one new feature. Versions ======== This patch should install in any 2.0 kernel from 2.0.24 onwards. It should also install in any 2.1 kernel from 2.1.120 onwards. The installation procedure has been tested on 2.0.24, 2.0.30, 2.0.35 and 2.1.120. The patches themselves have been tested on 2.0.30, 2.0.35 and 2.1.120. Caldera COL 1.0 was used for 2.0.30. Red Hat 5.1 was used as the base system for testing 2.0.35 and 2.1.120. The patch cannot be removed via the "Remove" script from kernel versions prior to 2.0.35. To Install ========== From the directory in which the gdbstub patches and this README file reside, become root and enter: ./Install This will install the gdbstub patches in the kernel source tree at /usr/src/linux. It will ask you if you want to install in that source tree, and if you answer "n" you can enter the directory name of the kernel source tree in which you wish the patch to be installed. If there is any problem with the installation, if the patch utility returns an error code, for example, then there will be a file named patches.errs., where is the process id of the Install shell script. If the patch looks successful, then you are ready for a kernel rebuild. Do a "make clean" before you rebuild your kernel. The patch inserts a "-g" into the master Makefile so as to compile the kernel with debugging info set. You need to rebuild the whole thing so that all the pieces have debugging info. To Remove ========= From the directory in which the gdbstub patches and this README file reside, become root and enter: ./Remove This will back out the patches to the kernel source and remove the extra files that were inserted into the kernel tree by the installation procedure. Debugging Setup =============== Designate one machine as the "development" machine. This is the machine on which you run your compiles and which has your source code for the kernel. Designate a second machine as the "target" machine. This is the machine that will run your experimental kernel. The two machines will be connected together via a serial line out one or the other of the COM ports of the PC. You will need a modem eliminator and the appropriate cables. On the development machine you need to apply the patch for the gdb hooks. Use the following installation procedure. Remember, you are on the DEVELOPMENT machine patching the kernel source for the kernel that you intend to run on the TARGET machine. Copy this kernel to your target machine using your usual procedures. I usually arrange to copy development:/usr/src/linux/arch/i386/boot/zImage to /vmlinuz on the TARGET machine via a LAN based NFS access. That is, I run the cp command on the target and copy from the development machine via the LAN. Run Lilo on the new kernel on the target machine so that it will boot! Then boot the kernel on the target machine. The installation procdure compiles a utility program named "gdbstub." You should copy this program over to your target machine, probably into /usr/local/bin. This utility program is run on the target machine to activate the kernel hooks for the debugger. It is invoked as follows: gdbstub [-s speed] [-t tty-dev] defaults: /dev/ttyS0 with speed unmodified by gdbstub Don't run the program just yet. We'll get to that in a bit. Decide on which tty port you want the machines to communicate, then cable them up back-to-back using the null modem. COM1 is /dev/ttyS0 and COM2 is /dev/ttyS1. On the DEVELOPMENT machine, create a file called .gdbinit in the directory /usr/src/linux. You will probably find it handy to add the stuff from the file gdbinit that came with the gdbstub patch to your .gdbinit file. You can include all your favorite gdb macros in this file. Assuming that you added my gdbinit stuff to your .gdbinit, edit .gdbinit and find the section that looks like this: define rmt set remotebaud 38400 target remote /dev/ttyS0 end Change the "target" definition so that it specifies the tty port that you intend to use. Change the "remotebaud" definition to match the data rate that you are going to use for the com line. On the TARGET machine I find it helpful to create shell script file named "debug" in the root home directory with the following contents: gdbstub -s 38400 -t /dev/ttyS0 < EOF This runs the gdbstub program and gives it the carriage return that it prompts for. This sets the data rate from the target machine's side. You are now ready to try it out. On your target machine, freshly rebooted with your gdbstub-equipped kernel, type "debug" in the root home directory. The system will appear to hang with some messages on the screen from the debug stub. What it is doing is waiting for contact from the development machine. On your development machine, cd /usr/src/linux and enter "gdb vmlinux". When gdb gets the symbols loaded and prompts you, enter "rmt" (that's the macro from the .gdbinit file that you just edited). If everything is working correctly you should see gdb print out a few lines indicating that a breakpoint has been taken. It will actually show a line of code in the target kernel inside the gdbstub activation code. The gdb interaction should look something like this: linux-dev:/usr/src/linux# gdb vmlinux GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.15.1 (i486-slackware-linux), Copyright 1995 Free Software Foundation, Inc... (gdb) rmt breakpoint () at i386-stub.c:750 750 } (gdb) You can now use whatever gdb commands you like to set breakpoints. Enter "continue" to start your target machine executing again. At this point the target system will run at full speed until it encounters your breakpoint or gets a segment violation in the kernel, or whatever. The "gdbstub" Program ===================== This utility program is used to set up the com port and data rate for the connection from the target system to the development system. Its usage has been described above. This version of the patch uses the same tty ioctl for kernel versions 2.0.30 onwards. Thus, the gdbstub utility does not need to be re-compiled to install the patch in a later version of the kernel. The ioctl added to the kernel for this purpose is far enough "off the end" of existing ioctls (as of 2.1.120) that it should not interfere with any new kernel tty ioctls for quite some time (famous last words). Debugging hints =============== You can break into the target machine at any time from the development machine by typing ^C. If the target machine has interrupts enabled this will stop it in the kernel and enter the debugger. There is unfortunately no way of breaking into the kernel if it is in a loop with interrupts disabled, so if this happens to you then you need to place exploratory breakpoints or printk's into the kernel to find out where it is looping. When you are done debugging the kernel on the target machine it is a good idea to leave it in a running state. This makes reboots faster, bypassing the fsck. So do a gdb "continue" as the last gdb command if this is possible. To terminate gdb itself on the development machine and leave the target machine running, type ^Z to suspend gdb and then kill it with "kill %1" or something similar. If it doesn't work, you will have to troubleshoot it. Do the easy things first like double checking your cabling and data rates. You might try some non-kernel based programs to see if the back-to-back connection works properly. Just something simple like cat /etc/hosts >/dev/ttyS0 on one machine and cat /dev/ttyS0 on the other will tell you if you can send data from one machine to the other. There is no point in tearing out your hair in the kernel if the line doesn't work. All of the real action takes place in the file /usr/src/linux/arch/i386/kernel/i386-stub.c. That is the code on the target machine that interacts with gdb on the development machine. In gdb you can turn on a debug switch with the following command: set remotedebug This will print out the protocol messages that gdb is exchanging with the target machine. Another place to look is /usr/src/linux/drivers/char/serialstub.c. That is the code that talks to the serial port on the target side. There might be a problem there. If you are really desperate you can use printk debugging in the gdbstub code in the target kernel until you get it working. In particular, there is a global variable in /usr/src/linux/arch/i386/kernel/i386-stub.c named "remote_debug". Compile your kernel with this set to 1, rather than 0 and the debug stub will print out lots of stuff as it does what it does. I picked up this code from a gdb source code release and modified it to make it work. Most of the hard work was done by the original authors. If you make some really cool modification to this stuff, or if you fix a bug, please let me know. In particular, if anyone figures out how to do source level debugging of loadable modules using this setup, please let me, and others, know. New Feature =========== There is only one new feature in this version of gdbstub. That is the ability to type ^C from the development machine to interrupt the execution of the target kernel. If you have an older version of gdbstub installed you can add this feature by modifying a file in the kernel source tree. See the file README.FEATURE for guidance. Changes ======= 06Jan97 David Grothe gdbstub.c use pause() rather than wait() 06Jan*** David Grothe Update for kernel version 2.0.30 31Aug*** Jack Thomasson Allow ^C to stop target kernel 12Sep*** David Grothe Update for kernel version 2.0.35 03Oct*** David Grothe Update for kernel version 2.1.xx David Grothe

近期下载者：

相关文件：

评论：[我要评论] [举报此文件]

收藏者：