The recommended rate is Connect the null-modem cable to the COM ports that you have chosen for debugging on the host and target computers. On the host computer, open WinDbg. On the File menu, choose Kernel Debug. In the Baud rate box, enter the rate you have chosen for debugging.
Select OK. You can also start a session with WinDbg by entering the following command in a Command Prompt window; n is the number of the COM port used for debugging on the host computer, and rate is the baud rate used for debugging:. On the host computer, open a Command Prompt window, and enter the following command, where n is the number of the COM port used for debugging on the host computer, and rate is the baud rate used for debugging:. On the host computer, you can use environment variables to specify the COM port and the baud rate.
Then you do not have to specify the port and baud rate each time you start a debugging session. To use environment variables to specify the COM port and baud rate, open a Command Prompt window and enter the following commands, where n is the number of the COM port used for debugging on the host computer, and rate is the baud rate used for debugging:.
To start a debugging session, open a Command Prompt window, and enter one of the following commands:. Determine the numbers of the COM ports you are using for debugging on the host and target computers. For example, suppose you have your null-modem cable connected to COM1 on the host computer and COM2 on the target computer. This section is divided into two subsections. The first describes adding the module itself and the second describes enabling the module.
In the appropriate conf directory, you need to add your files or modules into various files. These are supplemented by files , files. The format for these two files is relatively straightforward.
If you are adding a new module, you should first choose a name for that module. The first part defines the name of the module as it will be used in if statements in the code. See Modifying the Source Code Files for more information. The second part is always the word optional. This also applies if you are adding a file to an existing module. If you are adding a file that is not associated with any module at all, you add a line that looks like the following to specify that this file should always be included:.
To enable a module option as described in the files files , you must add an entry for that option into one of the MASTER files. If your code is not a BSD pseudo-device, you should add something like the following:. When your code checks to see if it should be included, it can also check that number and allocate resources for more than one pseudo-device.
The meaning of multiple pseudo-devices is device-dependent. An example of this is ppp , which allocates resources for two simultaneous PPP connections. In the OS X kernel, all source code files are automatically compiled. It is the responsibility of the C file itself to determine whether its contents need to be included in the build or not.
Assume that you want this file to compile only on PowerPC-based computers. It is created by the makefiles themselves. You must run make exporthdrs before make all to generate these files. Before you can build a kernel, you must first obtain source code.
To find out your current kernel version , use the command uname -a. If you run into trouble, search the archives of the darwin-kernel and darwin-development mailing lists for information.
Next, you will need to compile several support tools. Extract the files from these. Finally, issue the following commands :. One final step remains: compiling kextsymboltool. You now have all the necessary tools, libraries, and header files to build a kernel. The next step is to compile the kernel itself. First, change directories into the xnu directory. Next, you need to set a few environment variables appropriately. For your convenience, the kernel sources contain shell scripts to do this for you.
If you are using sh, bash, zsh, or some other Bourne-compatible shell, issue the following command:. The release configuration should be the same as a stock Apple-released kernel, so this is interesting only if you are building source that differs from that which was used to build the kernel you are already running.
The ddb debugger is helpful to debug panics that occur early in boot or within certain parts of the Ethernet driver. It is also useful for debugging low-level interrupt handler routines that cannot be debugged by using the more traditional gdb. To compile an alternate kernel configuration, you should follow the same basic procedure as outlined previously, changing the final make statement slightly. For information on modifying these files, see the section Enabling Module Options.
Kernel panics are simply a fact of life during development of kernel extensions or other in-kernel code. There are a number of ways to track down problems in kernel code. In many cases, you can find the problem through careful use of printf or IOLog statements. Some people swear by this method, and indeed, given sufficient time and effort, any bug can be found and fixed without using a debugger.
These flags are relevant to both gdb and ddb debugging and are important enough to warrant their own section. For most computers, the default is for Open Firmware to present a command—line prompt on your monitor and accept input from your keyboard. For some older computers you must use a serial line at , 8N1.
Technically, such computers are not supported by OS X, but some are usable under Darwin, and thus they are mentioned here for completeness. From an Open Firmware prompt, you can set the flags with the setenv command. From the OS X command line, you would use the nvram command.
Note that when modifying these flags you should always look at the old value for the appropriate Open Firmware variables and add the debug flags. For example, if you want to set the debug flags to 0x4 , you use one of the following commands. For computers with recent versions of Open Firmware, you would type. For older firmware versions, the interesting variable is boot-command.
Thus, you might do something like. Of course, the more important issue is what value to choose for the debug flags. Table lists the debugging flags that are supported in OS X. Send kernel debugging printf output to console. Allow debugger to ARP and route allows debugging across routers and removes the need for a permanent ARP entry, but is a potential security hole —not available in all kernels.
The last option is only available in Mac OS Macintosh computers have various watchdog timers designed to protect the system from certain types of failures. There are two primary watchdog timers in common use: the power management watchdog timer not present on all systems and the system crash watchdog timer.
Both watchdogs are part of the power management hardware. The first of these, the power management watchdog timer, is designed to restore the system to a known safe state in the event of unexpected communication loss between the power management hardware and the CPU. This timer is only present in G4 and earlier desktops and laptops and in early G5 desktops.
With the possible exception of a momentary loss of keyboard and mouse control, you probably won't notice that anything has happened and you should never even experience such a stall unless you are writing a device driver that disables interrupts for an extended period of time.
The problem occurs when the disruption in communication is caused by entering the debugger while the PMU chip is in one of these "unsafe" states. If the chip is left in one of these "unsafe" states for too long, it will shut the computer down to prevent overheating or other problems. This problem can be significantly reduced by operating the PMU chip in polled mode.
This prevents the watchdog timer from activating. You should only use this option when debugging, however, as it diminishes performance and a crashed system could overheat. The second type of watchdog timer is the system crash watchdog timer. This is normally only enabled in OS X Server. If your target machine is running OS X Server, your system will automatically reboot within seconds after a crash to maximize server uptime. You can disable this automatic reboot on crash feature in the server administration tool.
Click OK. You can also start a session with WinDbg by opening a Command Prompt window and entering the following command, where n is your port number and MyKey is the key that was automatically generated by bcdedit when you set up the target computer:. If you are prompted about allowing WinDbg to access the port through the firewall, allow WinDbg to access the port for all three of the different network types. On the host computer, open a Command Prompt window. Enter the following command, where n is your port number and MyKey is the key that was automatically generated by bcdedit when you set up the target computer:.
Once the debugger is connected, and waiting to connect, reboot the target computer. One way to do restart the PC is to use this command, from an administrator's command prompt.
After connecting to the target on the host, hit break on your debugger and you can start debugging. When you first attempt to establish a network debugging connection, you might be prompted to allow the debugging application WinDbg or KD access through the firewall. Client versions of Windows display the prompt, but Server versions of Windows do not display the prompt.
You should respond to the prompt by checking the boxes for all three network types: domain, private, and public. If you do not get the prompt, or if you did not check the boxes when the prompt was available, you must use Control Panel to allow access through the firewall.
Use the check boxes to allow those two applications through the firewall. Restart your debugging application WinDbg or KD. To keep the target computer secure, packets that travel between the host and target computers must be encrypted.
We strongly recommend that you use an automatically generated encryption key provided by bcdedit when you configure the target computer. Network debugging uses a bit key that is specified as four bit values, in base 36, separated by periods. Each bit value is specified by using up to 13 characters. Valid characters are the letters a through z and the digits 0 through 9. Special characters are not allowed.
To specify your own key, open an elevated Command Prompt window on the target computer. Enter the following command, where w. Scroll down and click OK , to save the firewall changes. Restart the debugger. The range of port numbers that can be used for network debugging might be limited by your company's network policy.
To determine whether your company's policy limits the range of ports that can be used for network debugging, check with your network administrator. The output will be similar to this. In the preceding output, the value of port is If the value of port lies outside the range allowed by your network administrator, enter the following command, where w. After changing the target machine debugger settings, rerun the debugger on the host machine with the new port setting, and then reboot the target computer.
Note that this may not work if your host computer is not configured to be discoverable on the network, since the firewall may block ping requests, and because of this, you will not get any responses when you ping the host.
Local link IP addresses are not routable, so a host and target cannot use a local link IP address to communicate through a router. In that case, network debugging will work if you plug the host and target computers into the same network hub or switch.
To specify the bus parameters, Open Device Manager, and locate the network adapter that you want to use for debugging. Open the property page for the network adapter, and make a note of the bus number, device number, and function number. In an elevated Command Prompt Window, enter the following command, where b , d , and f are the bus, device and function numbers in decimal format:.
0コメント