64位Linux汇编井字棋程序出现Segmentation Fault问题求助

Hey there! Let's troubleshoot that segmentation fault you're facing while porting your 16-bit MS-DOS Tic-Tac-Toe to 64-bit Linux assembly. Segfaults in x86-64 Linux almost always stem from invalid memory access or mismatched system conventions, so let's break down the most likely issues based on your code snippets and the huge jump from DOS to Linux:

1. Misconfigured Memory Pointers/Arrays #

Looking at your .bss section:

game_position_pointer resb 9

The name suggests this is a pointer, but resb 9 allocates 9 bytes of uninitialized space. In 64-bit Linux, pointers are 8 bytes—if you're treating this as a pointer to a 9-byte game state buffer, you're either:

• Storing a malformed pointer (since 9 bytes is too big for a 64-bit address), leading to random memory access, or
• Confusing a pointer with an array.

Fix: If you need a direct array for game positions, rename and define it as:

section .bss
game_position resb 9  ; 9-byte array for X/O/_ positions, no pointer needed
key resb 1

If you truly need a pointer (e.g., for dynamic allocation), use resq 1 to reserve an 8-byte pointer slot, then initialize it with a valid address (via brk syscall or similar) before using it.

2. Incorrect System Call Logic #

DOS relies on INT 21h for system calls, but 64-bit Linux uses the syscall instruction with entirely different register conventions. If your code still uses DOS-style interrupts (like int 21h), executing a privileged interrupt in user-space will immediately trigger a segfault.

Fix: Use Linux x86-64 syscalls properly. For example, to print your game_start_message:

; Print game start message to stdout
mov rax, 1          ; Syscall number for sys_write
mov rdi, 1          ; File descriptor: stdout (1)
mov rsi, game_start_message
mov rdx, gsm_size   ; Precomputed length of the message
syscall             ; Execute the syscall

Remember: Linux syscalls don't rely on NULL-terminated strings—you must pass the exact length via rdx.

3. Stack Mismanagement #

16-bit DOS uses a 16-bit stack, but 64-bit Linux requires a 64-bit stack that maintains 16-byte alignment for syscalls/function calls. If your code still uses 16-bit stack operations (e.g., push ax, pop bx), you'll corrupt the stack alignment, leading to invalid memory accesses.

Fix:

• Replace all 16-bit register stack operations with 64-bit equivalents (push rax instead of push ax, pop rbx instead of pop bx).
• Ensure the stack is 16-byte aligned before calling syscall—you can adjust the stack with sub rsp, 8 if needed (since syscall itself preserves alignment but some operations may break it).

4. Uninitialized Memory Access #

Your game_position_pointer is in .bss, which is zero-initialized, but if you're using it as a pointer without pointing it to valid memory, you'll be accessing address 0 (or random garbage if you messed up the pointer size), which is invalid in user-space.

Fix: If using a dynamic pointer, initialize it first. For example, to allocate 9 bytes via brk:

; Get current break address
mov rax, 12         ; Syscall number for sys_brk
mov rdi, 0
syscall
mov rbx, rax        ; Save current break

; Extend break by 9 bytes
mov rax, 12
mov rdi, rbx
add rdi, 9
syscall
mov [game_position_pointer], rbx  ; Store pointer to new memory

Or, as mentioned earlier, just use a static array in .bss to avoid dynamic allocation entirely.

5. Array Index Out-of-Bounds #

If your code writes to indices beyond 8 in the 9-byte game state buffer, you'll access memory outside the allocated .bss space, which can trigger a segfault (or corrupt other variables, leading to unexpected behavior).

Fix: Add bounds checks in your input handling logic—ensure any user input maps to indices 0-8 before writing to the game buffer.

To pinpoint exactly where the segfault happens:

1. Compile your assembly with debug symbols: nasm -f elf64 your_program.asm -g -o your_program.o
2. Link it: ld your_program.o -o your_program
3. Run in GDB: gdb ./your_program
   • Type run to start the program
   • When it crashes, type bt to get a stack trace
   • Use info registers to check register values, and x/16x $rsp to inspect the stack

This will tell you exactly which instruction is causing the invalid memory access.

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