寻找更多的调试器

C-l修复了显示，并使用gdb -tty $ SOME_OTHER_TTY阻止了显示的混乱。

即使源窗口具有焦点，Readline绑定（C-n，C-p等）仍在命令窗口中工作。 focus cmd将焦点移到命令窗口，因此我可以再次使用箭头键。

C-x A应该会切换tui，但对我而言，无论是在alacritty还是xterm中，都崩溃了。我目前已针对nix对此进行了举报，因为这是最有可能的罪魁祸首。 （不编辑，这是一个gdb错误）。

这样更好-我得到了一个可点击的线程列表，回溯和本地列表。

它将所有本地人显示为＆＃34;＆lt;复杂数据类型＆gt;＆＃34;。这不是超级有帮助。有一个修补程序可以改善此问题，但似乎由于法律问题而延迟了。

对于gdb，这需要vscode扩展名，而我在上一篇文章中无法使用它，因此我没有进一步研究。

您在CLion中遇到的几个问题是我以前遇到的，值得庆幸的是，其中两个可以解决，一个可以解决。

（可能）不会显示您的变量，因为CLion依靠其语言支持来计算变量的精确范围（可悲的是，GDB不支持此DWARF功能），但是很遗憾，默认情况下假定变量始终为如果其语言支持无法将调试符号映射到声明，则超出范围。 （看来Zig插件没有任何调试器集成）。因此，您需要单击调试窗格左侧的齿轮图标（在屏幕快照中，隐藏在底部的＆gt;＆gt;符号后面），然后取消选中＆＃34;隐藏范围外的变量＆＃ 34;。

要使用“内存视图”，您需要右键单击任何变量，然后选择＆＃34;在内存视图中显示＆＃34 ;，这实际上会导致窗格加载。我不知道为什么需要这样做，因为一旦加载窗格，“内存视图”就完全能够导航到原始地址或由任意表达式计算的地址。

您（可能）无法通过UI设置断点，因为Zig插件不会将Zig文件类型注册为能够在其上设置断点的功能。不幸的是，没有编写插件就无法解决此问题，但是您仍然可以使用GDB控制台设置断点。不过，它们不会在会话之间持久存在，也不会显示在用户界面中。

两种修复程序均有效。现在，我可以看到变量并在内存视图中打开它们。

内存视图不支持编辑内存，但是我仍然可以在gdb控制台中执行此操作。

我在手表列表中添加了*actual.items.ptr@100，它使整个数组完美地呈现出来。

首先，似乎可以在gdb控制台中设置断点，但是重新启动程序以到达断点却没有。如果我使用调试器中的按钮重新运行，则断点将消失。如果我尝试从gdb中重新启动程序，它将崩溃：

（gdb）info断点没有断点或观察点。（gdb）b Tree.searchForwardsBreakpoint 1位于0x207222：文件/home/jamie/focus/lib/focus/tree.zig，第591行。 ;不支持。（gdb）start正在调试的程序已经启动。从头开始吗？ （是或否）[回答是；输入不是来自终端] 0x2097dc处的临时断点2：文件/nix/store/5g4w66g606d46w8pmzwzq7flrlk3k7cs-zig/lib/zig/std/start.zig，第243行。启动程序：/ home / jamie / focus / test 1＆gt; ＆＃39; / dev / pts / 4＆＃39; 2＆gt; ＆＃39; / dev / pts / 5＆＃39;在启动过程中，程序以代码1退出。

我可以通过启动程序，立即暂停，设置断点然后恢复来使其正常工作。

像其他大多数调试器一样，保持F8继续运行平稳。但是，与大多数其他调试器不同，在我释放键之前，本地变量将停止显示，因此我无法实时观察更改。

我使用向导创建了一个新的C ++项目，然后点击＆＃34; Debug Main Project＆＃34;。最初我虽然什么都没发生，但是过了一会儿我注意到屏幕右下方的红色小消息框。

它初次出现时实际上更大，但在几秒钟没有被注意到时它会缩小。

它还说我应该做一些类似netbeans -J-Dcnd.tmpbase =＆＃34; / home / jamie / netbeans-project＆＃34;的事情。但这会产生相同的错误消息，仍然引用＆＃34; / tmp＆＃34;而不是我给它的目录。我拼错了吗？

实际上似乎并没有尝试写＆tmp / tmp＆＃34;。当我按“调试主项目”时，它实际上根本不发出任何系统调用。并触发消息。因此，我认为这只是错误地报告了其他一些错误。潜在的问题可能又与nix有关。

另外...因为软件很难，所以我尽量避免对软件泛滥。但是，如果您给我一条错误消息，然后使错误文本变为不可选择，然后在上下文菜单中仅提供“标记为已读”。而不是＆＃34;复制到剪贴板，这样我就可以谷歌搜索此＆＃34;然后会使调试慢很多。

与gdb -tui大致相似。它显示了源代码窗口，并且具有许多有用的键盘快捷键，但是它不显示很多环境信息，例如当前回溯或局部变量。一切似乎都正常，但这不是我想要的。

似乎没有内存视图或显示任意表达式的方法。我尝试在gdb控制台中添加display（* actual.items.ptr）@ 100，但它没有出现在屏幕上的任何位置，也没有在第一次后在控制台中打印结果。

大型数组的渲染有点烦人-您必须在开始时单击以显示更多元素，但它们会出现在末尾。因此，要在屏幕上显示整个内容，需要进行大量滚动。

＆next＆＃39;的键绑定也是kate使用的，因此您必须进入绑定菜单并进行歧义消除。没什么大不了的，除了它在单个会话的过程中重置了几次外，所以我不得不继续访问绑定菜单。

gdb的初始化文件，其中添加了仪表板，该仪表板在程序停止时会打印，也可以在其他时间挂接以进行打印。

太好了它不提供gui的简单点击功能，但是确实在屏幕上可靠地放置了许多有用的上下文。它可以做到这一点，而不会像我尝试的大多数gui前端那样破坏或隐藏gdb的基本功能。

我仍在寻找一个好的gui调试器，但这是我在此期间要使用的。

Loris Cro建议使用voltron，它类似于gdb-dashboard，但在单独的终端中打开各种视图并实时更新它们。这似乎是一个严格的改进，我真的很喜欢这个主意。

在经历了通常的python依赖管理问题之后，我设法偶尔运行了一些voltron视图，但是大多数情况下还是设法使它反复崩溃，偶尔也使gdb崩溃。

（gdb崩溃位于printf内的某个位置，因此这可能与上面的tui崩溃是同一问题。）

如果我在文件选择器中键入完整路径，则会弹出＆＃34;发生错误＆＃34;。您必须键入目录名，然后从列表中选择文件。

当我运行程序时，它到达了断点，然后UI停止响应按钮单击，并偶尔吐出一些消息，说gdb主线程正在阻塞。

在终端中执行C-c之后，它留下了一堆ophan gdb进程，这些进程阻止了gdbfrontend重新启动。

drosan解释说，在ddd中，焦点跟随在鼠标上，这解释了为什么我在文本框中键入时遇到麻烦。

gef和pwndbg向gdb添加了一堆命令，这些命令对于底层调试和反向工程很有用。 Radar2是一组用于同一目的的独立工具，可以选择性地连接到gdb。我目前对这些没有太多用处，但是很高兴了解它们。

pernosco是我一直关注的项目。目前尚无法以业余爱好买得起，但是我可以想象当我再次开始从事商业工作时为此付费。

frida将javascript代码注入二进制文件。至少，这可以进行事后的println调试。我已经在日历中预留了一个周末来尝试一下。

我认为眨眼是一种尽可能直接地观察代码执行的方法，因此您可以直观了解硬件上实际发生的情况。我很快尝试了一下，并在退出代码0之前渲染了一个帧。但是它很有趣，我记下了笔记，然后在明年再次尝试。

到目前为止，我还没有尝试过许多专有选项。尽管我对foss工具有强烈的偏好，但只要我能在不通过电子邮件向销售团队发送报价的情况下进行试用，就可以接受有关专有工具的建议。