多操作系统的支持

对多操作系统的支持，最简单的实现就是针对不同的操作系统，设定不同的内核边界断点。这个可以通过在launch.json中增加一个配置项来实现。在另一个调试器插件Cortex-Debug中，有一个名为rtos的配置字段，其实现方式可以作为参考。 引入该配置的另一个重要意义在于，后续对内核数据结构解析相关的功能，也可以通过这个配置项来决定如何解析内存数据。

自动定位内核边界

目前在内核边界处的断点是以源文件名和行号的形式来定位的。这也就意味着如果对应的文件发生了变化，将直接导致调试器不可用，也就是说这是另一个硬编码的问题。

解决这个问题有两种思路，一种是将内核边界断点的行号做成可配置的，用户可以在launch.json中指定出入口断点所在的源码文件及行号。这样做的方式是简单快捷可以实现功能，但是对用户来说并不是很友好。

另一种思路是，可以通过解析被调试的ELF文件，依据其中的调试信息，以及反汇编代码，自动定位到内核的出入口。例如可以把与satp有关的操作作为识别特征，用于辅助定位出入点地址。结合上述多操作系统支持部分提到的配置，可以根据用户设置的不同目标OS，使用不同的定位策略。

在最终的实现上，可以将第二种思路作为首选，同时提供第一种思路的相关配置用于备选。

自动跳过内核边界断点

目前由于需要在内核态和用户态切换的过程中，使用断点的形式来通知调试器地址空间发生变化，每次到达内核边界时都会导致IDE直接进入到暂停状态，比较影响用户体验。一个解决思路是在launch.json中增加一个名为auto_skip_inout_point的配置项，当其值为true时，如果发现当前暂停的位置是断点所在位置，那么Adapter可以把这个消息吞掉，并且通知GDB直接继续运行，这样VSCode本身就会认为没有发生过断点命中，调试体验会有较大提升。

内存数据解析

前面说了很多已经做的和可以做的，但大部分都是在外围兜兜转转，主要是一些交互、UI上的改进，和操作系统这个核心话题其实有点远了，这个内存数据解析其实才是最压轴的功能点。

目前有一个可供大家参考的调试器插件叫做Cortex-Debug,一个用来调试ARM处理器的调试器插件，里面集成了对rtos操作系统的支持，可以将不同线程的调用栈、线程的名称等，都列出来，如下图所示：