| rs需要启动gpu设备 启用gpu调试层是干嘛的 | 您所在的位置：网站首页 › 启用gpu调试层是什么意思 › rs需要启动gpu设备 启用gpu调试层是干嘛的 |
rs需要启动gpu设备 启用gpu调试层是干嘛的
|
调试单元在处理器设计中往往是幕后英雄，大多数人对其软硬件实现机制也是不明就里，或者根本未曾关注。但是，最不起眼的，往往是最难的，调试机制是个非常复杂的软硬件协作机制，软硬件的实现难度很大。 一、调试机制概述对于处理器的调试功能而言，常用的两种是“交互式调试”和“追踪调试”。 1.1 交互调试概述交互调试（Interactive Debug）功能是处理器提供的最常见的一种调试功能，从最低端的处理器到最高端的处理器，交互调试几乎是必备的功能。交互调试是指调试器软件（比如常见的调试软件GDB）能够直接对处理器取得控制权，进而对其以一种交互的方式进行调试，比如通过调试软件对处理器。 下载或者启动程序。通过设定各种特定条件来停止程序。查看处理器的运行状态。包括通用寄存器的值，存储器的地址的值等。查看程序的状态。包括变量的值，函数的状态等。改变处理器的运行状态。包括通用寄存器的值，存储器地址的值等。改变程序的状态。包括变量的值，函数的状态等。对于嵌入式平台而言，调试器软件一般是运行于主机PC端的一款软件，而被调试的处理器往往是在嵌入式开发板之上，这是交叉编译和远程调试的一种典型情形。调试器软件为何能够取得处理器的控制权，从而对其进行调试呢？需要硬件的支持才能做到。在处理器核的硬件中，往往需要一个硬件调试模块。该调试模块通过物理介质（比如JTAG接口）与主机端的调试软件进行通信接受其控制，然后调试模块对处理器核进行控制。 为了帮助读者进一步理解，以交互式调试中常见的一种调试情形为例来阐述此过程。假设调试软件GDB试图对程序中的某个PC地址设置一个断点，然后希望程序运行到此处之后停下来，之后GDB能够读取处理器当时的某个寄存器的值。调试软件和调试模块便会进行如下协同操作。 开发人员通过运行于主机端的GDB软件在其软件界面设置某行程序的断点，GDB软件通过底层驱动JTAG接口访问远程处理器的调试模块，对其下达命令，告诉其希望于某PC设置一个断点。调试模块得令即开始对处理器核进行控制，首先他会请求处理器核停止；然后修改存储器中那个PC地址的指令，将其替换成一个Breakpoint指令；最后将处理器核放行，让处理器恢复执行。当处理器恢复执行后，执行到那个PC地址时，由于碰到了Breakpoint指令，会产生异常进入调试模式的异常服务程序。调试模块探测到处理器核进入了调试模式的异常服务程序，并将此信息显示出来。主机端的GDB软件一直在监测调试模块的状态从而得知此信息，便知处理器核已经运行到断点处停止了下来，并显示在GDB软件界面上。开发人员通过运行于主机端的GDB软件在其软件界面上设置读取某个寄存器的值，GDB软件通过底层驱动JTAG接口访问远程处理器的调试模块，对其下达命令，告诉其希望读取某个寄存器的值。调试模块得令即开始对处理器核进行控制，从处理器核中将那个寄存器的值读取出来，并将此信息显示出来。主机端的GDB软件一直在检测调试模块的状态，从而得知此信息，便通过JTAG接口将读取的值返回到主机PC端，并显示在GDB软件界面上。注意：以上采用极为通俗的语言来描述此过程，以帮读者理解，但难免失之严谨，请以具体的调试机制文档为准。 从上述过程中可以看出，调试机制是一套复杂的软硬件协同工作机制，需要调试软件和硬件模块的精密配合。 同时，也可以看出交互式调试对于处理器的运行往往是具有打扰性的。调试单元会在后台偷偷地控制住处理器核，时而让其停止，时而让其运行。由于交互式调试对处理器运行的程序具有影响，甚至会改变其行为，尤其是对时间先后性有依赖的程序，有时候交互式调试并不能完整地重现某些程序的 Bug。最常见的情形便是处理器在全速运行某个程序时会出现 Bug，当开发人员使用调试软件对其进行交互式调试时， Bug 又不见了。其主要原因往往就是交互式调试过程的打扰性，使得程序在调试模式和全速运行下的结果出现了差异。 1.2 跟踪调试概述为了克服交互式调试的打扰性，引入了跟踪调试（Trace Debug）机制。 跟踪调试，即调试器只跟踪记录处理器核执行过的所有程序指令，而不会打断干扰处理器的执行过程 。 跟踪调试同样需要硬件的支持才能做到，相比交互式调试的实现难度更大。由于处理器的运行速度非常快，每秒钟能执行上百万条指令，如果长时间运行某个程序，其产生的信息量十分巨大。跟踪调试器的硬件单元需要跟踪记录下所有的指令，对于处理速度的要求，数据的压缩、传输和存储等都是极大挑战 。跟踪调试器的硬件实现会涉及相比交互调试而言更加复杂的技术，同时硬件开销也更大， 因此跟踪调试器往往只在比较高端的处理器中使用 。 二、RISC-V架构的调试机制由于处理器可以有不同的调试实现机制，且与微架构的实现有关，比如有的调试机制追求以较小的面积实现调试的功能，有的调试机制追求以较快的调试反应速度而付出较大的面积开销。因此RISC-V基金会目前还没有发布标准的RISC-V调试架构文档，但是有若干公开的候选文档在审核之中。 目前公开的候选调试架构文档中，比较有影响力当属 SiFive 公司的方案，如下图所示。可以从SiFive公司网站下载其文档。“0.11版本”。
完整的调试机制需要调试器软件（ Debugger，比如 GDB ）和硬件精密协作。上节中曾列举了软硬件如何精密配合，达到向程序中设置断点和读取寄存器的通俗示例 。 感兴趣的读者若要试图严谨地理解调试机制，并结合调试器软件和硬件调试模块通过软硬件精密协作的方式实现所有的调试功能，可以参见“ 0.11版本”原文 。 2.2 调试模式“ 0 .11 版本”中定义了一种特殊的处理器模式一一调试模式（ Debug Mode ），同时定义了若干种触发条件，处理器核一旦遇到此类触发条件便会进入调试模式 。 可以将进入调试模式当成一种特殊的异常，进入调试模式时，处理器核会进行如下更新 。 处理器PC跳转到0x800地址。将处理器正在执行的指令PC保存到CSR寄存器dpc中。将引发进入调试模式的触发原因保存到CSR寄存器dcsr中。2.3 调试指令RISC-V 标准指令集中定义了 一条特殊的断点指令 ebreak，此指令主要用于调试软件设置断点。当处理器核执行到这条指令时会跳转到异常模式或者调试模式。 “ 0.11 版本”中还定义了一条特殊的指令 dret（注意和 mret 区分）。dret 指令执行后，处理器核会进行如下更新。 处理器PC跳转到保存在dpc中的值，这意味着处理器退回到之前进入调试模式之前的程序执行点。将dcsr寄存器中的域清除掉，指示处理器退出了调试模式。2.4 调试机制CSR“ 0.11 版本”中定义了几个只能在调试模式下访问到的 CSR 寄存器。请参见“ 0.1 l 版本”原文了解其详情。 2.5 调试中断“ 0.11 版本”中定义了一个特殊的处理器中断类型一调试中断（ Debug Interrupt ） 。 当处理器核收到此中断之后，将进入调试模式 。 调试中断是最主要的进入调试模式的触发条件，挑调试器软件的众多功能均依赖于此中断 。 关于调试中断的详细信息，请参见“ 0. 11 版本”原文 。
|
【本文地址】