gcc - 如何解决QEMU GDB调试错误: Remote 'g' packet reply is too long?

Question

我目前正在进入引导加载程序和内核开发(非常多的开始)
我正在结合以下
https://www.cs.bham.ac.uk/~exr/lectures/opsys/10_11/lectures/os-dev.pdf
以及中的代码
https://github.com/cfenollosa/os-tutorial

我唯一做的不同的是我的目标是x86_64而不是i386。另外，我正在使用qemu进行仿真(qemu-system-x86_64)。
现在，按照GitHub仓库中第16部分的视频驱动程序进行操作后，我被卡住了，因为屏幕驱动程序确实在屏幕上打印了一些内容，但是由于数据未对齐或其他原因而发生了某些事情。因此，接下来我想尝试调试程序。 repo 的第14部分-检查点中也对此进行了介绍。因此，我为目标x86_64-elf构建了gdb。但是当我尝试使用system-qemu-x86_64 -s -S -fda os-image运行qemu和gdb时
然后只要运行gdb并尝试通过运行target remote localhost:1234来连接到qemu，一旦运行，我将收到以下错误消息

Remote debugging using localhost:1234
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Remote 'g' packet reply is too long (expected 308 bytes, got 536 bytes):
000000000000000000000000000000000000000000000000630600000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000f0ff0000000000000200000000f00000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000007f03000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000
00000000000000000000000000000000000000000000000000000000801f0000

关于我缺少/做错的任何想法吗？如果需要更多信息，请告诉我。

谢谢

编辑:
我已经应用了@MichaelPetch提到的补丁，现在g数据包错误消失了。但是看起来gdb无法解释我的可执行文件，因为先运行 target remote localhost:1234然后运行 symbol-file kernel.elf，终端现在返回

Remote debugging using localhost:1234 warning: No executable has been
specified and target does not support determining executable automatically.
Try using the "file" command. 0x0000fb38 in ?? ()

但是我可以在函数和行号上设置断点。但是当尝试使用 print terminal_buffer打印应该在当前位置可用的变量时，我得到了 No symbol "terminal_buffer" in current context. terminal_buffer是在当前作用域中声明的变量。

但是，当我打印在断点所在的函数范围之外声明的变量时，例如一个int， print确实返回一个值，但该值为0(但是，我认为这是该类型的初始值)根据我的代码，它应该已经设置为新值。另外，当尝试 next时，它返回 Cannot find bounds of current function，这导致我认为它无法解释某些部分。

在我的引导加载程序中，我使用以下方法进入 protected 保护模式以运行64位内核:

[bits 16]
switch_to_pm:
    cli ; 1. disable interrupts
    lgdt [gdt_descriptor] ; 2. load the GDT descriptor
    mov eax, cr0
    or eax, 0x1 ; 3. set 32-bit mode bit in cr0
    mov cr0, eax
    jmp CODE_SEG:init_pm ; 4. far jump by using a different segment

[bits 32]
init_pm: ; we are now using 32-bit instructions
    mov ax, DATA_SEG ; 5. update the segment registers
    mov ds, ax
    mov ss, ax
    mov es, ax
    mov fs, ax
    mov gs, ax

    mov ebp, 0x90000 ; 6. update the stack right at the top of the free space
    mov esp, ebp

    call BEGIN_PM ; 7. Call a well-known label with useful code

有什么想法吗？

Answer 1

出现所有问题的原因是，您正在编译64位代码并以32位保护模式运行它。 64位代码将无法在该环境中正确运行。奇怪的是，在尝试写入视频显示器时，它通常一开始就表现出来。通常情况下会打印出来，但并不是您想要的那样。解码不正确的指令将导致调试器无法正常运行，如您观察到的那样。

解决问题的一种方法是将内核编译和链接为32位可执行文件。您使用的是64位编译器，因此需要添加-m32 CFLAGS(或GCC命令行)。如果需要使用LD链接-melf_i386。与NASM组装应该是-felf32而不是-felf64。

或者，您必须在引导加载程序中将处理器置于64位长模式。您可以在OSDev wiki上阅读有关该过程的更多信息。

如果调试32位代码，则可能要使用qemu-system-i386。您将减少麻烦。