Section 5.1. Arranging for the Kernel to Execute

5.1. Arranging for the Kernel to Execute

The Mac OS X kernel is a Mach-O executable that resides as /mach_kernel by default on a boot volume. Recall that in Chapter 4, we examined the kernel executable using the otool program to determine the kernel's entry point. When the kernel is compiled, the final linking stage arranges several aspects of the executable, such as the following:

• The executable's entry point is set to _start [osfmk/ppc/start.s]. The LC_UNIXTHREAD load command in the Mach-O header contains the entry point's value in the SRR0 register of the thread state.

• The address of the __VECTORS segment is set to 0x0.

• The address of the __HIB segment, which is used to implement hibernation, is set to 0x7000.

• The address of the __TEXT segment is set to 0xe000.

• The __text section in the __TEXT segment has its alignment set to 0x1000 (4096 bytes).

• The __common section in the __DATA segment has its alignment set to 0x1000 (4096 bytes).

• The __bss section in the __DATA segment has its alignment set to 0x1000 (4096 bytes).

• A __text section is created (with the contents of /dev/nulli.e., with no contents) in the __PRELINK segment. Similarly, sections __symtab and __info are created from /dev/null in the __PRELINK segment.

5.1.1. Exceptions and Exception Vectors

The __VECTORS segment contains the kernel's exception vectors. As we saw in Chapter 4, BootX copies these to their designated locationsstarting at address 0x0before calling the kernel. These vectors are implemented in osfmk/ppc/lowmem_vectors.s. Table 51 contains an overview of PowerPC exceptions, most of which are subject to one or more conditions. For example, exceptions caused by failed effective-to-virtual address translations occur only if address translation is enabled. Moreover, most exceptions can occur only when no higher-priority exception exists.

Table 51. PowerPC Exceptions

Vector Offset	Exception	xnu Interrupt ("rupt") Code	Cause/Comments
0x0100	System reset	T_RESET	A hard or soft processor reset. This exception is nonmaskable and asynchronous.
0x0200	Machine check	T_MACHINE_CHECK	Various causes: parity error detection in the L1 cache, the TLB, or the SLB; uncorrectable ECC error detection in the L2 cache; etc. May be recoverable or unrecoverable.
0x0300	Data access	T_DATA_ACCESS	A page fault or erroneous data memory access, such as an operation with invalid memory rights.
0x0380	Data segment	T_DATA_SEGMENT	Effective address of a storage location failed to be translated to a virtual address.
0x0400	Instruction access	T_INSTRUCTION_ACCESS	Similar to data access exception, but for instructions.
0x0480	Instruction segment	T_INSTRUCTION_SEGMENT	Effective address of the next instruction to be executed failed to translate to a virtual address.
0x0500	External interrupt	T_INTERRUPT	Asserted by an external interrupt input signal.
0x0600	Alignment	T_ALIGNMENT	Various alignment-related causes: e.g., certain load/store instructions encountered misaligned operands.
0x0700	Program	T_PROGRAM	Various causes: e.g., floating-point exception, or exception due to the execution of an illegal or privileged instruction.
0x0800	Floating-point unavailable	T_FP_UNAVAILABLE	Floating-point unit unavailable or disabled.
0x0900	Decrementer	T_DECREMENTER	The decrementer is negative.
0x0a00	I/O controller interface error	T_IO_ERROR	Unused on Mac OS X.
0x0b00	Reserved	T_RESERVED
0x0c00	System call	T_SYSTEM_CALL	The system call (sc) instruction is executed.
0x0d00	Trace	T_trACE	Single-step tracing or branch tracing is enabled and an instruction successfully completed.
0x0e00	Floating-point assist	T_FP_ASSIST	A floating-point operation needs software assistance.
0x0f00	Performance monitor	T_PERF_MON	Various performance-monitoring exception conditions.
0x0f20	Vector processing unit unavailable	T_VMX	VMX is unavailable or disabled.
0x1000	Instruction translation miss	T_INVALID_EXCP0	Unused on Mac OS X.
0x1100	Data-load translation miss	T_INVALID_EXCP1	Unused on Mac OS X.
0x1200	Data-store translation miss	T_INVALID_EXCP2	Unused on Mac OS X.
0x1300	Instruction address breakpoint	T_INSTRUCTION_BKPT	The 970FX only supports this feature through a support-processor interface.
0x1400	System management	T_SYSTEM_MANAGEMENT	Implementation-dependent.
0x1500	Soft Patch	T_SOFT_PATCH	Implementation-dependent softpatch facility emitted a special exception-causing internal operation. Used for working around defective instructions and for debugging.
0x1600	AltiVec Java Mode assist/maintenance	T_ALTIVEC_ASSIST	Implementation-dependent maintenance exception. Can be signaled by various internal events and by explicit commands.
0x1700	AltiVec Java Mode assist/thermal	T_THERMAL	An input operand or the result of an operation was denormalized while operating in AltiVec Java Mode.
0x1800	Thermal (64-bit)	T_ARCHDEP0	Signaled by assertion of a thermal interrupt input signal.
0x2000	Instrumentation	T_INSTRUMENTATION	Unused on Mac OS X.
0x2100	VMM ultra-fast path		Filter ultra-fast path system calls for the virtual machine monitor (VMM)[a] facility in the Mac OS X kernel. Not used in Mac OS X 10.4.

^[a] We will discuss the VMM facility in Section 6.9.

Most hardware exceptions in the Mac OS X kernel are channeled through a common exception-handling routine: exception_entry() [osfmk/ppc/lowmem_vectors.s]. The designated exception handler saves GPR13 and GPR11, sets a "rupt" code in GPR11, and jumps to exception_entry. For example, the following is the exception handler for T_INSTRUCTION_ACCESS:

            . = 0x400 .L_handler400:             mtsprg  2,r13                     ; Save R13             mtsprg  3,r11                     ; Save R11             li      r11,T_INSTRUCTION_ACCESS  ; Set rupt code             b       .L_exception_entry        ; Join common

Note that several exceptions in Table 51 may do "nothing," depending on the hardware being used, whether the kernel is being debugged, and other factors.

5.1.2. Kernel Symbols

Two other related files are usually present on the root volume: /mach.sym and /mach. The /mach.sym file contains symbols from the currently running kernel. It is meant for use by programs that need to access kernel data structures. In some cases, the on-disk kernel executable may not correspond to the running kernelfor example, in the case of a network boot. In fact, there may not even be a kernel executable present on the root file system. To address this issue, the kernel can generate a dump of its own symbols and write it to a designated file. This file's pathname can be retrieved using the KERN_SYMFILE sysctl, which provides read access to the kern.symfile sysctl variable.

$ sysctl kern.symfile kern.symfile = \mach.sym

The kernel implementation of the KERNEL_SYMFILE sysctl checks whether /mach.sym is open by looking at a global Boolean variable. If it is not open, the kernel outputs kernel symbols to /mach.sym and marks it as open. The kernel does not dump symbols to /mach.sym if the root device is being accessed over the network, if /mach.sym exists as a nonregular file, or if it exists as a file with a link count of more than one. This symbol-file creation is triggered during user-level system startup from /etc/rc, which uses the sysctl command to retrieve the value of the kern.symfile variable.

# /etc/rc ... # Create mach symbol file sysctl -n kern.symfile if [ -f /mach.sym ]; then         ln -sf /mach.sym /mach else         ln -sf /mach_kernel /mach fi

We see that if /mach.sym exists, /mach is created as a symbolic link to it, otherwise /mach is a symbolic link to /mach_kernel. Moreover, since /mach.sym is useful only if it corresponds to the running kernel, it is deleted and recreated during every boot.

$ ls -l /mach* lrwxr-xr-x   1 root  admin        9 Mar 10 16:07 /mach -> /mach.sym -r--r--r--   1 root  admin   598865 Mar 10 16:07 /mach.sym -rw-r--r--   1 root  wheel  4330320 Feb  3 20:51 /mach_kernel

Note that the kernel supports dumping symbols only once per bootif you delete /mach.sym, running the sysctl command will not regenerate it unless you reboot.

The symbols in /mach.sym are the same as in the running kernel's executable, although section references in the symbol table are converted to absolute references. In fact, /mach.sym is a Mach-O executable containing a load command for the __TEXT segment, a load command for the __DATA segment, and an LC_SYMTAB load command for the symbol table. Only the __const section of the __TEXT segment is nonempty, containing the kernel vtables.

$ otool -hv /mach.sym /mach.sym: Mach header       magic cputype cpusubtype   filetype ncmds sizeofcmds      flags    MH_MAGIC     PPC        ALL    EXECUTE     3        816   NOUNDEFS $ otool -l /mach.sym ... Load command 2      cmd LC_SYMTAB  cmdsize 24   symoff 184320    nsyms 11778   stroff 325656  strsize 273208 $ nm -j /mach_kernel > /tmp/mach_kernel.sym $ nm -j /mach.sym > /tmp/mach.sym.sym $ ls -l /tmp/mach_kernel.sym /tmp/mach.sym.sym -rw-r--r--   1 amit  wheel  273204 Mar 10 19:22 /tmp/mach.sym.sym -rw-r--r--   1 amit  wheel  273204 Mar 10 19:22 /tmp/mach_kernel.sym $ diff /tmp/mach_kernel.sym /tmp/mach.sym.sym # no output produced by diff $ nm /mach_kernel | grep __start_cpu 00092380 T __start_cpu $ nm /mach.sym | grep __start_cpu 00092380 A __start_cpu

5.1.3. Run Kernel Run

Figure 51 shows a very high level overview of Mac OS X system startup. In the rest of this chapter, we will look at details of the steps listed in the "Kernel" and "User" boxes.

Figure 51. A high-level view of Mac OS X system startup

The qualifications low-level and high-level are subjective and approximate. For example, the I/O Kitspecifically the platform driver, such as AppleMacRISC4PEhandles certain low-level aspects of processor initialization, but the I/O Kit is not active during very early kernel startup.