Assembly Language & x86 Low-Level Systems Programming · レッスン

カスタム例外ハンドラー

特定のエラー条件を最低レベルで処理するために、独自のカスタム例外ハンドラーを記述して登録する方法を学びます。

「カスタム例外ハンドラー」はCoddyKit上の無料Assembly Language & x86 Low-Level Systems Programmingレッスンです。これはレッスン3/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAssembly Language & x86 Low-Level Systems Programming学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Assembly Language & x86 Low-Level Systems Programmingコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

Intercepting System Errors

Custom exception handlers are special routines that take control when the CPU encounters an unexpected event, known as an exception. These events can range from programming errors like dividing by zero to memory access violations.

Instead of the system crashing, a custom handler allows you to intercept these events, diagnose the problem, or even recover gracefully. This is crucial for operating systems and low-level debugging.

CPU's Response to Exceptions

When an exception occurs, the CPU performs a series of critical steps before executing any handler code:

It pushes the current EFLAGS, CS (Code Segment), and EIP (Instruction Pointer) onto the stack.
For some exceptions (like page faults), an error code is also pushed.
The CPU then looks up the corresponding entry in the Interrupt Descriptor Table (IDT) to find the address of the exception handler.
Finally, it transfers control to that handler.

Anatomy of an Exception Handler

A robust exception handler must carefully manage the CPU's state. Its core responsibilities include:

Saving Context: Pushing all general-purpose registers (GPRs) onto the stack to preserve their values.
Processing: Analyzing the exception, perhaps reading the error code or the saved EIP to locate the faulting instruction.
Restoring Context: Popping the saved GPRs from the stack in reverse order.
Returning: Using the iret (or iretd for 32-bit) instruction to return control to the interrupted program or operating system.

Failing to save/restore registers correctly can lead to system instability.

A Basic Handler Snippet

Here's a conceptual structure for an exception handler. Remember, this specific snippet isn't runnable on its own; setting up an actual handler requires kernel-level privileges and a proper operating system context.

; --- Conceptual Exception Handler Snippet ---
; (Not runnable as a standalone program)

my_exception_handler:
    pushad              ; Save all 32-bit GPRs (EAX, ECX, EDX, EBX, ESP, EBP, ESI, EDI)

    ; --- Handler Logic Goes Here ---
    ; Example: Read error code (if present), analyze EIP
    ; mov ebp, esp      ; Can use EBP to access stack frame
    ; mov eax, [ebp + 36] ; Example: Access EIP
    ; ... perform error logging, recovery, etc. ...

    popad               ; Restore all GPRs
    add esp, 4          ; Adjust stack if an error code was pushed by CPU
                        ; (depends on exception type)
    iret                ; Return from interrupt/exception

IDT Entry for Exceptions

To register our custom handler, we need to populate an entry in the Interrupt Descriptor Table (IDT). This entry is typically an interrupt gate descriptor (or trap gate for exceptions).

Key fields in this 8-byte descriptor include:

Offset: The 32-bit address of our handler function.
Segment Selector: Identifies the code segment our handler resides in.
DPL (Descriptor Privilege Level): The minimum privilege level required to call this interrupt/exception.
Type: Specifies it's an interrupt or trap gate.

Crafting a Gate Descriptor

Manually building an interrupt gate descriptor involves carefully placing the handler's address and attributes into specific bytes. This is usually done in assembly or C code within a low-level environment.

For a 32-bit interrupt gate:

Bits 0-15 of the offset go into bytes 0-1.
The segment selector goes into bytes 2-3.
Flags (P, DPL, Type) go into byte 5.
Bits 16-31 of the offset go into bytes 6-7.

This ensures the CPU knows exactly where to jump and with what privileges.

Activating Your Handler

Once the gate descriptor is crafted, it needs to be written into the correct slot in the IDT. This typically involves:

Calculating the IDT entry's physical address (IDT_base + (exception_number * 8)).
Writing the 8-byte descriptor to that memory location.

Important: Modifying the IDT usually requires kernel-level privileges (Ring 0). User-mode programs cannot directly alter the IDT, as this would compromise system security and stability.

Handling INT 0 (Divide-by-Zero)

One of the most common and simple exceptions is the Divide-by-Zero exception (INT 0). This occurs when an integer division instruction attempts to divide by zero.

A custom handler for INT 0 could:

Print an error message to a debug console.
Log the faulting instruction's address.
Terminate the faulty process gracefully.
In some cases, even attempt to correct the divisor or result and resume execution.

This allows controlled error handling instead of a raw system crash.

Causing a Divide-by-Zero

Here's a simple assembly program that will intentionally cause a divide-by-zero exception. When you run this, your operating system's default exception handler for INT 0 will take over and likely terminate the program.

The goal of a custom handler, as discussed, would be to replace that default behavior with our own logic.

; compile with: nasm -f elf32 -o divbyzero.o divbyzero.asm
; link with: ld -m elf_i386 -s -o divbyzero divbyzero.o

section .data
    msg db "Attempting divide by zero...", 10, 0

section .text
    global _start

_start:
    ; Print message (using Linux sys_write)
    mov eax, 4          ; sys_write
    mov ebx, 1          ; stdout
    mov ecx, msg        ; message address
    mov edx, 30         ; message length
    int 0x80            ; call kernel

    ; Set up for division
    mov eax, 10         ; Dividend
    mov ebx, 0          ; Divisor (will cause exception)
    
    ; Perform division - this will trigger INT 0
    div ebx             ; EAX / EBX -> EAX (quotient), EDX (remainder)

    ; This code will not be reached if exception occurs
    mov eax, 1          ; sys_exit
    xor ebx, ebx        ; exit code 0
    int 0x80

Handler Responsibilities

When creating a custom exception handler, what crucial steps must be performed to ensure system stability and proper execution?

Custom Handlers: Recap

In this lesson, we explored the world of custom exception handlers. We learned:

Why handlers are vital for system robustness and debugging.
The CPU's sequence of actions when an exception occurs.
The essential structure of a handler: saving context, processing, restoring context, and returning via iret.
The role of the Interrupt Gate Descriptor in the IDT for registering handlers.
The conceptual steps for building and loading a descriptor, noting the privilege requirements.

Understanding these low-level mechanisms is key to advanced system programming and operating system development.

よくある質問

「カスタム例外ハンドラー」レッスンは無料ですか？

はい。「カスタム例外ハンドラー」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Assembly Language & x86 Low-Level Systems Programmingコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Assembly Language & x86 Low-Level Systems Programmingコースには全4レッスンが含まれています。

「カスタム例外ハンドラー」で何を学びますか？

特定のエラー条件を最低レベルで処理するために、独自のカスタム例外ハンドラーを記述して登録する方法を学びます。ブラウザで直接実行するハンズオンコードでAssembly Language & x86 Low-Level Systems Programmingを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Assembly Language & x86 Low-Level Systems Programmingを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAssembly Language & x86 Low-Level Systems Programmingは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン3/4です。

「カスタム例外ハンドラー」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAssembly Language & x86 Low-Level Systems Programmingレッスンでコードを書いて実行できますか？

はい。すべてのAssembly Language & x86 Low-Level Systems Programmingレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← Assembly Language & x86 Low-Level Systems Programmingに戻る