Assembly 使用gdb在qemu中调试时内存位置错误

我正在用汇编语言编写一个小内核。我在QEMU中运行它，并且有一些bug问题。现在我想用dbg调试内核。所以我把它组装成这样：

$ nasm -g -f elf -o myos.elf myos.asm
$ objcopy --only-keep-debug myos.elf myos.sym
$ objcopy -O binary myos.elf myos.bin

然后我在QEMU中运行它：

$ qemu-system-i386 -s -S myos.bin

然后我连接到gdb：

$ gdb
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x0000fff0 in ?? ()
symbol-file myos.sym
Reading symbols from /home/sven/Projekte/myos/myos.sym...done.

我的内核中有一个名为

welcome

的标签，它指向一个字符串。测试时，我尝试查看该字符串，结果如下：

(gdb) x/32b welcome
0x1e <welcome>: 0x00    0xf0    0xa5    0xfe    0x00    0xf0    0x87    0xe9
0x26:   0x00    0xf0    0x6e    0xc9    0x00    0xf0    0x6e    0xc9
0x2e:   0x00    0xf0    0x6e    0xc9    0x00    0xf0    0x6e    0xc9
0x36:   0x00    0xf0    0x57    0xef    0x00    0xf0    0x6e

所以你可以看到，gdb假装欢迎以空字节开始，但根据定义它不是。但是内核正确地使用了标签，所以我的代码似乎没有问题。检查内存的其他部分与加载的内核根本不匹配

有人知道为什么虚拟机的内存与加载的内核不匹配，而机器仍能正常工作吗？

解释

• qemu-system-i386

  在运行时在地址

  0x7c00

  处加载x86引导扇区映像文件的第一个字节
• 您的ELF文件（

  myos.ELF

  ，

  myos.sym

  ）错误地通知GDB将在地址0处加载代码。因此，GDB认为

  welcome

  位于

  0x1e

  ，而实际上位于

  0x7c1e

• 将

  0x7c00

  添加到GDB中的所有地址可能会起作用，但很笨拙：

  x/32xb（欢迎+0x7c00）

• 更好的解决方案是创建具有正确地址的ELF文件

解决方案 boot.asm

; 'boot.asm' ; loaded by BIOS [bits 16] global main main: mov di, welcome print_welcome: mov ah, 0x0e mov al, [di] int 0x10 inc di cmp byte [di], 0 jne print_welcome hlt db "XXXXXXXXXXXXXX" ; some padding to make welcome appear at 0x1e welcome: db "System started. Happy hacking!", 10, 0 ; x86 boot sector padding and signature ; NOTE: intentionally commented out. Will be added by linker script ;times 510 - ($ - $$) db 0x00 ;db 0x55, 0xAA 使用GDB在内存中搜索

欢迎

消息也会显示正确的地址：

(gdb) find 0, 0xffff, 'S', 'y', 's', 't' 0x7c1e （gdb）查找0，0xffff，'S'，'y'，'S'，'t' 0x7c1e 进一步阅读

• ：参见关于LMA与VMA的讨论
• ：上面链接器脚本的源。展示了用于x86实模式开发的一些很酷的GNU工具链技巧

解释

• qemu-system-i386

  在运行时在地址

  0x7c00

  处加载x86引导扇区映像文件的第一个字节
• 您的ELF文件（

  myos.ELF

  ，

  myos.sym

  ）错误地通知GDB将在地址0处加载代码。因此，GDB认为

  welcome

  位于

  0x1e

  ，而实际上位于

  0x7c1e

• 将

  0x7c00

  添加到GDB中的所有地址可能会起作用，但很笨拙：

  x/32xb（欢迎+0x7c00）

• 更好的解决方案是创建具有正确地址的ELF文件

解决方案 boot.asm

; 'boot.asm' ; loaded by BIOS [bits 16] global main main: mov di, welcome print_welcome: mov ah, 0x0e mov al, [di] int 0x10 inc di cmp byte [di], 0 jne print_welcome hlt db "XXXXXXXXXXXXXX" ; some padding to make welcome appear at 0x1e welcome: db "System started. Happy hacking!", 10, 0 ; x86 boot sector padding and signature ; NOTE: intentionally commented out. Will be added by linker script ;times 510 - ($ - $$) db 0x00 ;db 0x55, 0xAA 使用GDB在内存中搜索

欢迎

消息也会显示正确的地址：

(gdb) find 0, 0xffff, 'S', 'y', 's', 't' 0x7c1e （gdb）查找0，0xffff，'S'，'y'，'S'，'t' 0x7c1e 进一步阅读

• ：参见关于LMA与VMA的讨论
• ：上面链接器脚本的源。展示了用于x86实模式开发的一些很酷的GNU工具链技巧

  ---

谢谢你的帮助。现在我想查看堆栈，但%sp指向零。还有一些偏移量我必须处理吗？@IchUndNichtDu，

p$esp

在GDB中应该显示

0x6f20

，带有我答案中的代码。如果你不能让它工作，就用完整的源代码和GDB命令发布新问题。问它谢谢你的工作。现在我想查看堆栈，但%sp指向零。还有一些偏移量我必须处理吗？@IchUndNichtDu，

p$esp

在GDB中应该显示

0x6f20

，带有我答案中的代码。如果你不能让它工作，就用完整的源代码和GDB命令发布新问题 target remote localhost:1234 symbol-file boot monitor system_reset # run until hlt instruction, address obtained through disassembly until *0x7c0f x/32xb welcome monitor quit disconnect quit $ qemu-system-x86_64 -s -S boot.good.bin & $ gdb -q -x dump-welcome.gdb 0x0000fff0 in ?? () main () at boot.asm:16 16 hlt 0x7c1e : 0x53 0x79 0x73 0x74 0x65 0x6d 0x20 0x73 0x7c26: 0x74 0x61 0x72 0x74 0x65 0x64 0x2e 0x20 0x7c2e: 0x48 0x61 0x70 0x70 0x79 0x20 0x68 0x61 0x7c36: 0x63 0x6b 0x69 0x6e 0x67 0x21 0x0a 0x00 $ python -c 's = "System started. Happy hacking!"; print [hex(ord(x)) for x in s ]' ['0x53', '0x79', '0x73', '0x74', '0x65', '0x6d', '0x20', '0x73', '0x74', '0x61', '0x72', '0x74', '0x65', '0x64', '0x2e', '0x20', '0x48', '0x61', '0x70', '0x70', '0x79', '0x20', '0x68', '0x61', '0x63', '0x6b', '0x69', '0x6e', '0x67', '0x21'] (gdb) find 0, 0xffff, 'S', 'y', 's', 't' 0x7c1e