汇编语言中打印自定义错误的标准方法探讨

Great question! I totally get where you're coming from—storing every single custom error string in the data section can get bloated and hard to maintain, especially as your program grows. Let's walk through the standard, more efficient approaches for printing custom errors in assembly, tailored to different use cases.

This is the most common approach for reducing redundant string definitions. You define a single generic format string, then pass dynamic values (like error descriptions, codes, or filenames) to fill in the gaps. This works especially well if you're linking against the C standard library (for functions like fprintf), but you can also implement a minimal version with raw syscalls if needed.

Here's an example for x86 Linux using libc:

section .data
    ; Generic error format string (supports a message and error code)
    err_format db "Error: %s (error code: %d)", 0xA, 0
    ; Specific error messages (only unique ones)
    file_open_err db "Failed to open target file", 0
    mem_alloc_err db "Memory allocation failed", 0

section .text
    extern fprintf
    global main

main:
    ; Example: Print "Error: Failed to open target file (error code: 2)" to stderr
    push 2                  ; Error code (ENOENT)
    push file_open_err      ; Specific error message
    push err_format         ; Format string
    push 2                  ; File descriptor for stderr
    call fprintf            ; Call libc's fprintf
    add esp, 16             ; Clean up the stack

    ; Exit program
    mov eax, 0
    ret

The win here is minimizing duplicate string overhead—you only need one format string, and reuse it for all your error cases by swapping out the dynamic parameters.

If you need even more flexibility (like generating error messages with runtime-specific values, e.g., dynamic file paths or calculated error codes), you can build the message on the fly in a buffer (either in the .bss section or on the stack). This avoids predefining any error strings at all for dynamic content.

Here's a raw syscall example for x86 Linux, which converts an integer error code to a string and builds a full error message:

section .bss
    err_buffer resb 64      ; Buffer to hold the dynamically built message

section .text
global _start

_start:
    ; Build "Error code: 42" in err_buffer
    mov esi, err_buffer

    ; Copy static prefix to buffer
    mov eax, "Error "
    mov [esi], eax
    add esi, 6
    mov eax, "code: "
    mov [esi], eax
    add esi, 6

    ; Convert error code (42) to string and append to buffer
    mov ebx, 42
    call int_to_string

    ; Write the buffer to stderr
    mov edx, esi - err_buffer  ; Calculate message length
    mov ecx, err_buffer
    mov ebx, 2                 ; stderr file descriptor
    mov eax, 4                 ; sys_write syscall number
    int 0x80

    ; Exit program
    mov eax, 1
    xor ebx, ebx
    int 0x80

; Helper function: Convert integer in EBX to ASCII string, write to ESI
; ESI will point to the end of the string after return
int_to_string:
    push ebx
    push ecx
    push edx
    mov ecx, 0

    ; Handle zero case
    cmp ebx, 0
    jne .loop
    mov byte [esi], '0'
    inc esi
    jmp .end

.loop:
    xor edx, edx
    mov eax, ebx
    mov ebx, 10
    div ebx         ; EAX = quotient, EDX = remainder
    mov ebx, eax
    add dl, '0'     ; Convert remainder to ASCII
    push dx         ; Push digit to stack (to reverse later)
    inc ecx
    cmp ebx, 0
    jne .loop

.pop_loop:
    pop dx
    mov [esi], dl
    inc esi
    dec ecx
    jnz .pop_loop

.end:
    pop edx
    pop ecx
    pop ebx
    ret

This approach is great for saving data segment space and handling dynamic values that can't be predefined. The tradeoff is a bit more code for string manipulation, but it's worth it for complex error messages.

If your errors are tied to system call failures (like open returning -1), you can use the system's built-in error message library instead of writing your own. On Linux, the strerror function converts an error code (from errno) to a human-readable string.

Example using libc:

section .data
    error_prefix db "System error: ", 0

section .text
    extern strerror, fprintf
    global main

main:
    ; Assume we got error code 2 (ENOENT = No such file or directory)
    push 2
    call strerror        ; Returns pointer to system's error string
    push eax             ; Push that string pointer
    push error_prefix    ; Push our custom prefix
    push 2               ; stderr file descriptor
    call fprintf         ; Print "System error: No such file or directory"
    add esp, 12

    ret

This is perfect for standard system errors—you don't have to maintain any error strings and users get consistent, familiar error messages.

Which Approach Should You Use? #

• Reuse format strings: Best for most cases where you have fixed error categories (e.g., "file not found", "invalid input").
• Dynamic buffer building: Ideal when you need runtime-specific values in error messages (e.g., "Failed to read 123 bytes from file.txt").
• System-provided strings: Perfect for system call errors, to avoid reinventing the wheel.

Your original method isn't wrong—it's just not the most scalable. These approaches will keep your code cleaner and more efficient as you add more error handling.

内容的提问来源于stack exchange，提问作者Setin