用惯了宇宙第一的 Visual Studio 再用其他的开发工具还是有一点不习惯，不习惯在于想用的命令或者面板找不到，总的来说还是各有千秋吧，今天我们来聊一下几个在调试中比较实用的命令：

相信大家都知道 Visual Studio 直接提供了 Memory 面板来观察内存布局，但 VSCode 没有，还需要自己手敲命令来实现，这就比较麻烦了，为了方便先上一段测试代码。

调试器配的是 GDB，只能用它的 x 命令观察内存，类似 WinDbg 的 d系列命令，我们在 int c=12 处下个断点，命中后使用 -exec x/40xw $esp 观察 esp处的内存块，截图如下：

这里的 x/40xw $esp 是什么意思呢？ 翻译成 WinDbg 的术语就是 dd esp L40 的意思，也就是显示 40 个 dword 指针单元的内存地址。

从内存地址上看 a，b 都存放在线程栈上，虽然没有 VS 便捷，但还是可以用的。

说实话到现在都没搞明白为什么 Visual Studio 不支持硬件断点，其实是可以做的，熟悉 WinDbg 的朋友都知道有一个 ba 命令就是专门用来设置硬件断点，硬件断点牛的地方在于可以对 内存地址 的读写进行监控，不过它需要 CPU 的调试寄存器支持，即 dr0 ~ dr7 。

比如我在 windbg 中对 04ee5000 下一个读断点，输出如下：

在 GDB 中也有类似的 硬件断点，即 rwatch 和 awatch 命令，前者用来监视读操作，后者监视 读写操作，这里我们测试下 awatch 命令，测试代码如下：

接下来在 int b=11 处下断点，通过 x 命令找到 a 所在的内存地址，然后使用 awatch 进行监控，不过有点坑的是 awatch 需要转成具体类型，相当于监视的范围宽度，输出如下：

从上面输出的信息看非常明确，也非常有意思，给 GDB 点一个赞。

这个貌似也是 VS 不具有的功能，在 GDB 中得到了支持，相当于 WinDBG 中的 !address 命令，观察虚拟地址布局好处多多，可以看到内存的分配情况，比如 stack 是否溢出就能从中观察得到，在 GDB 中可以使用 i proc mapping 命令，输出如下：

从输出看，当前的 stack 布局段在 0xfffdd000 ~ 0xffffe000 之间，如果发生了栈溢出就可以看下是不是超过这个范围了哈，除了 stack 还可以看到 heap 的段范围 0x5655a000 ~ 0x5657c000 。

GDB 有很多实用的命令这里就不逐一介绍了，至少在 Linux 上是霸主一样的存在，真搞不懂 netcore 的调试要和 lldb 扯在一块，简直是不走寻常路哈 😂😂😂