我的操作系统中使用了一个汇编程序，在 GRUB 之后运行，但我遇到了一个奇怪的问题，.word 65535 导致 QEMU 重新启动，我不明白为什么.
我已经做了一些测试，并且使用 jmp $ 找出了导致问题的行，并且我已确认它就是我上面提到的行。
我的多重启动兼容代码是:
/* Enable intel syntax */
.intel_syntax noprefix
/* Declare constants for the multiboot header. */
.set ALIGN, 1<<0 /* align loaded modules on page boundaries */
.set MEMINFO, 1<<1 /* provide memory map */
.set FLAGS, ALIGN | MEMINFO /* this is the Multiboot 'flag' field */
.set MAGIC, 0x1BADB002 /* 'magic number' lets bootloader find the header */
.set CHECKSUM, -(MAGIC + FLAGS) /* checksum of above, to prove we are multiboot */
/*
Declare a multiboot header that marks the program as a kernel. These are magic
values that are documented in the multiboot standard. The bootloader will
search for this signature in the first 8 KiB of the kernel file, aligned at a
32-bit boundary. The signature is in its own section so the header can be
forced to be within the first 8 KiB of the kernel file.
*/
.section .multiboot
.align 4
.long MAGIC
.long FLAGS
.long CHECKSUM
/*
The multiboot standard does not define the value of the stack pointer register
(esp) and it is up to the kernel to provide a stack. This allocates room for a
small stack by creating a symbol at the bottom of it, then allocating 16384
bytes for it, and finally creating a symbol at the top. The stack grows
downwards on x86. The stack is in its own section so it can be marked nobits,
which means the kernel file is smaller because it does not contain an
uninitialized stack. The stack on x86 must be 16-byte aligned according to the
System V ABI standard and de-facto extensions. The compiler will assume the
stack is properly aligned and failure to align the stack will result in
undefined behavior.
*/
.section .bss
.align 16
stack_bottom:
.skip 16384 # 16 KiB
stack_top:
/*
The linker script specifies _start as the entry point to the kernel and the
bootloader will jump to this position once the kernel has been loaded. It
doesn't make sense to return from this function as the bootloader is gone.
*/
.section .text
.global _start
.type _start, @function
_start:
/*
The bootloader has loaded us into 32-bit protected mode on a x86
machine. Interrupts are disabled. Paging is disabled. The processor
state is as defined in the multiboot standard. The kernel has full
control of the CPU. The kernel can only make use of hardware features
and any code it provides as part of itself. There's no printf
function, unless the kernel provides its own <stdio.h> header and a
printf implementation. There are no security restrictions, no
safeguards, no debugging mechanisms, only what the kernel provides
itself. It has absolute and complete power over the
machine.
*/
/*
To set up a stack, we set the esp register to point to the top of the
stack (as it grows downwards on x86 systems). This is necessarily done
in assembly as languages such as C cannot function without a stack.
*/
mov stack_top, esp
/*
This is a good place to initialize crucial processor state before the
high-level kernel is entered. It's best to minimize the early
environment where crucial features are offline. Note that the
processor is not fully initialized yet: Features such as floating
point instructions and instruction set extensions are not initialized
yet. The GDT should be loaded here. Paging should be enabled here.
C++ features such as global constructors and exceptions will require
runtime support to work as well.
*/
/*
GDT from the old DripOS bootloader, which was from the original
project (The OS tutorial)
*/
gdt_start:
.long 0x0
.long 0x0
gdt_code:
.word 65535 /* <-------- this line causing problems */
.word 0x0
/*.byte 0x0
.byte 0x9A*/ /*10011010 in binary*/
/*.byte 0xCF*/ /*11001111 in binary*/
/*.byte 0x0*/
jmp $
gdt_data:
.word 0xffff
.word 0x0
.byte 0x0
.byte 0x92 /*10010010 in binary*/
.byte 0xCF /*11001111 in binary*/
.byte 0x0
gdt_end:
gdt_descriptor:
.word gdt_end - gdt_start - 1
.long gdt_start
#CODE_SEG gdt_code - gdt_start
#DATA_SEG gdt_data - gdt_start
lgdt [gdt_descriptor]
jmp $
/*
Enter the high-level kernel. The ABI requires the stack is 16-byte
aligned at the time of the call instruction (which afterwards pushes
the return pointer of size 4 bytes). The stack was originally 16-byte
aligned above and we've since pushed a multiple of 16 bytes to the
stack since (pushed 0 bytes so far) and the alignment is thus
preserved and the call is well defined.
*/
call main
/*
If the system has nothing more to do, put the computer into an
infinite loop. To do that:
1) Disable interrupts with cli (clear interrupt enable in eflags).
They are already disabled by the bootloader, so this is not needed.
Mind that you might later enable interrupts and return from
kernel_main (which is sort of nonsensical to do).
2) Wait for the next interrupt to arrive with hlt (halt instruction).
Since they are disabled, this will lock up the computer.
3) Jump to the hlt instruction if it ever wakes up due to a
non-maskable interrupt occurring or due to system management mode.
*/
cli
1: hlt
jmp 1b
/*
Set the size of the _start symbol to the current location '.' minus its start.
This is useful when debugging or when you implement call tracing.
*/
.size _start, . - _start
我希望 QEMU 在调用 .word 65535 后继续工作，但 QEMU 会重新启动并且操作系统不会启动。
最佳答案
正如评论中所指出的，您将GDT放在代码中间。当混合时，处理器无法区分代码和数据。 CPU 会尝试在指令 mov stack_top, esp 之后开始执行 GDT 作为代码。目标文件上的 objdump -Dz -Mintel1 显示这些指令已被执行:
boot.o: file format elf64-x86-64 Disassembly of section .text: 0000000000000000 <_start>: 0: 89 24 25 00 00 00 00 mov DWORD PTR ds:0x0,esp 0000000000000007 <gdt_start>: 7: 00 00 add BYTE PTR [rax],al 9: 00 00 add BYTE PTR [rax],al b: 00 00 add BYTE PTR [rax],al d: 00 00 add BYTE PTR [rax],al 000000000000000f <gdt_code>: f: ff (bad) 10: ff 00 inc DWORD PTR [rax] 12: 00 eb add bl,ch 14: fe (bad) [snip]
CPU 本来能够将 GDT 中的第一个字节作为虚假指令执行，但是当它到达 gdt_code 中的 0xffff 时，该指令无法被解码为有效指令。 OBJDUMP 将其显示为(坏)。
修复方法很简单，正如 @Jester 所说 - 只需将 GDT(和所有数据)移到代码后面即可。首选是将数据和代码放在不同的部分中，以便将其分开。
脚注
1OBJDUMP选项含义:
-D选项显示代码反汇编-z选项显示文件中的所有零字节-Mintel使用 Intel 语法而不是默认的 AT&T 语法显示代码
关于assembly - 使用 .word 65535 会导致 QEMU 重新启动，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57771867/