您的位置:首页 > 文旅 > 旅游 > QEMU中GDB远程串行协议

QEMU中GDB远程串行协议

2024/10/7 4:37:03 来源:https://blog.csdn.net/u011832525/article/details/141259628  浏览:    关键词:QEMU中GDB远程串行协议

QEMU中GDB远程串行协议

  • 1 GDB远程串行协议介绍
  • 2 QEMU中“g”命令数据包
    • 2.1 获取x0~x31与pc寄存器
    • 2.2 获取f0 ~ f31、模式、CSR寄存器
      • 2.2.1 为何使用CPUState.gdb_num_regs
      • 2.2.2 如何修改
      • 2.2.3 数据包中寄存器布局

本文属于 《RISC-V指令集差分测试(DiffTest)系列教程》之一,欢迎查看其它文章。

1 GDB远程串行协议介绍

GDB(GNU Debugger)是一个强大的代码调试工具,它提供了一种使用串行通信协议进行远程调试的方法。

在GDB中,可以通过GDB服务器和GDB客户端进行远程调试。其中,GDB远程串行协议允许GDB客户端通过串行连接(如USB或TCP/IP)与GDB服务器通信。

GDB远程串行协议的主要作用是:允许开发者在一个系统(通常是开发主机)上,调试另一个系统(通常是目标设备)上运行的程序。这在调试嵌入式系统或需要物理访问硬件的情况下特别有用。

协议具体内容,参考官网:https://sourceware.org/gdb/current/onlinedocs/gdb.html/Remote-Protocol.html
中文含义介绍:https://www.cnblogs.com/linucos/archive/2013/03/01/2938836.html

2 QEMU中“g”命令数据包

NEMU的DiffTest中,就是基于上述GDB远程串行协议,来获取QEMU中模拟的内存,以及寄存器等信息的。

2.1 获取x0~x31与pc寄存器

“g”命令,表示获取QEMU中通用寄存器(x0~x31与pc)。

当NEMU通过调用gdb_getregs函数,向QEMU发送“g”命令时,QEMU会将当前模拟的CPU中,通用寄存器值,回传给NEMU。

回传的数据包,长度为528字节,内容假设为如下:

"1234567823456789…”
  • 每个字节必须为:“0” ~ “9"或"a” ~ “f"之间的任一字符
  • 每2个字节,表示1字节数据的十六进制,比如"12"表示0x12
  • 所表示数据,低位在前,高位在后

假设寄存器数据长度为8字节,那么"1234567823456789",低位在前,高位在后,即表示寄存器值为0x8967452378563412。

x0~x31与pc,一共33个寄存器,寄存器数据长度为33 * 8=264字节,因此需要使用264 * 2=528个字符来表示。

数据包中,寄存器排列顺序,如下所示:
在这里插入图片描述

2.2 获取f0 ~ f31、模式、CSR寄存器

原版QEMU6.2.0中,虽然通过g命令,能获取上述寄存器;但是,并不能获取到f0 ~ f31、当前模式、CSR这些寄存器。

首先,需要明白QEMU中,以下几个寄存器数变量,的含义:

  • CPUState.gdb_num_g_regs:表示gdb下’g’命令可获取的寄存器数量,此值为33
  • CPUClass.gdb_num_core_regs:表示gdb可访问的core寄存器数量,此值为33
  • CPUState.gdb_num_regs:表示gdb可访问的所有寄存器数,此值为4166。这4166个寄存器,是由如下组成的:
    • x0 ~ x31 + pc,共33个;
    • f0 ~ f31 + 4个浮点相关CSR寄存器(fflags、frm、fcsr、其他),共36个;
    • mode模式,共1个;
    • csr寄存器,12位地址,共4096个。

2.2.1 为何使用CPUState.gdb_num_regs

在qemu6.2.0/target/riscv/gdbstub.c的riscv_cpu_register_gdb_regs_for_features函数中,会为浮点以及CSR寄存器注册访问函数,如下:

void riscv_cpu_register_gdb_regs_for_features(CPUState *cs)
{RISCVCPU *cpu = RISCV_CPU(cs);CPURISCVState *env = &cpu->env;if (env->misa_ext & RVD) {gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,36, "riscv-64bit-fpu.xml", 0);} else if (env->misa_ext & RVF) {gdb_register_coprocessor(cs, riscv_gdb_get_fpu, riscv_gdb_set_fpu,36, "riscv-32bit-fpu.xml", 0);}if (env->misa_ext & RVV) {gdb_register_coprocessor(cs, riscv_gdb_get_vector, riscv_gdb_set_vector,ricsv_gen_dynamic_vector_xml(cs,cs->gdb_num_regs),"riscv-vector.xml", 0);}switch (env->misa_mxl_max) {case MXL_RV32:gdb_register_coprocessor(cs, riscv_gdb_get_virtual,riscv_gdb_set_virtual,1, "riscv-32bit-virtual.xml", 0);break;case MXL_RV64:case MXL_RV128:gdb_register_coprocessor(cs, riscv_gdb_get_virtual,riscv_gdb_set_virtual,1, "riscv-64bit-virtual.xml", 0);break;default:g_assert_not_reached();}gdb_register_coprocessor(cs, riscv_gdb_get_csr, riscv_gdb_set_csr,riscv_gen_dynamic_csr_xml(cs, cs->gdb_num_regs),"riscv-csr.xml", 0);
}

在gdb_register_coprocessor函数中,会对已注册的寄存器,进行数量累加,因此CPUState.gdb_num_regs才是所有寄存器总数

2.2.2 如何修改

如何修改QEMU源码,才能使得g命令,可以获取到所有寄存器的值呢?

非常简单。

将qemu6.2.0/gdbstub.c的handle_read_all_regs函数中gdb_num_g_regs改为gdb_num_regs,如下:

static void handle_read_all_regs(GArray *params, void *user_ctx)
{...for (addr = 0; addr < gdbserver_state.g_cpu->gdb_num_regs; addr++) {...}...
}

如此,便可获取到所有寄存器。

需要注意的是,这4166个寄存器,并不是每个寄存器都会在数据包中传输,若QEMU未实现的寄存器,就不会放入buf中,也就不会传输。

2.2.3 数据包中寄存器布局

经过调试发现,响应g命令时,实际能获取到的寄存器,只有209个,具体为以下这些:

  • x0 ~ x31 + pc
  • f0 ~ f31 + fflags + frm + fcsr
  • mode
  • 140个CSR寄存器,QEMU 6.2.0只支持140个CSR寄存器。

数据包中(总长度为3344字节),寄存器排列顺序,如下所示:
在这里插入图片描述

在数据包中,从前往后,这些CSR寄存器的地址,如下所示:

int csrAddr[140] = { 
0x1, 0x2, 0x3, 0x100, 0x104, 0x105, 0x106, 0x140, 0x141, 0x142, 0x143, 0x144, 0x180, 0x300, 0x301, 0x302, 0x303, 0x304, 0x305, 0x306, 
0x323, 0x324, 0x325, 0x326, 0x327, 0x328, 0x329, 0x32a, 0x32b, 0x32c, 0x32d, 0x32e, 0x32f, 0x330, 0x331, 0x332, 0x333, 0x334, 0x335, 0x336, 
0x337, 0x338, 0x339, 0x33a, 0x33b, 0x33c, 0x33d, 0x33e, 0x33f, 0x340, 0x341, 0x342, 0x343, 0x344, 0x3a0, 0x3a1, 0x3a2, 0x3a3, 0x3b0, 0x3b1, 
0x3b2, 0x3b3, 0x3b4, 0x3b5, 0x3b6, 0x3b7, 0x3b8, 0x3b9, 0x3ba, 0x3bb, 0x3bc, 0x3bd, 0x3be, 0x3bf, 0xb00, 0xb02, 0xb03, 0xb04, 0xb05, 0xb06, 
0xb07, 0xb08, 0xb09, 0xb0a, 0xb0b, 0xb0c, 0xb0d, 0xb0e, 0xb0f, 0xb10, 0xb11, 0xb12, 0xb13, 0xb14, 0xb15, 0xb16, 0xb17, 0xb18, 0xb19, 0xb1a, 
0xb1b, 0xb1c, 0xb1d, 0xb1e, 0xb1f, 0xc00, 0xc02, 0xc03, 0xc04, 0xc05, 0xc06, 0xc07, 0xc08, 0xc09, 0xc0a, 0xc0b, 0xc0c, 0xc0d, 0xc0e, 0xc0f, 
0xc10, 0xc11, 0xc12, 0xc13, 0xc14, 0xc15, 0xc16, 0xc17, 0xc18, 0xc19, 0xc1a, 0xc1b, 0xc1c, 0xc1d, 0xc1e, 0xc1f, 0xf11, 0xf12, 0xf13, 0xf14, };

即:fflags地址为0x1,frm地址为0x2,fcsr地址为0x3,sstatus地址为0x100,以此类推。

  • 后来测试QEMU 7.1.0,发现g命令,获取的CSR数量,比QEMU6.2.0时多了3个,为143个。
  • 看来,在不同QEMU版本中,实现的CSR数量,还是有区别的。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com