Visual Studio 开发与“Linux”的调试工作流程方面发展？
好的，所以有很多问题，要求“Linux 上的 Visual Studio 等效项”或这个问题的变体。 （此处，此处，这里，...）
我想关注一个方面并询问如何调试< /em> 工作流程在不同系统上可能有所不同，特别是 Visual Studio（类似）系统使用的完全集成 IDE 方法以及可能更“独立”的面向工具链的方法。
为此，让我介绍一下我认为的“Visual Studio 调试工作流程”的简短描述：
- 给定一个现有项目
- ，我打开该项目（从用户角度来看一个步骤），
- 我导航到我想要调试的代码（可能是通过搜索我的项目文件，这只需打开“在文件中查找”对话框即可完成。）
- 我在 (a) 行放置了一个断点，只需将光标放在该行上并点击 < code>F9
- 我在 (b) 行放置了一个“跟踪点”，方法是在该处添加断点，然后更改断点属性，以便调试器不会停止，而是跟踪局部变量的值。
- 我按下
F5，它会自动编译我的可执行文件，在调试器下启动它，然后我等到 prg 在 (a) 处停止，同时监视跟踪窗口以获取 (b) 的输出 - 。停在 (a) 处时，我的屏幕会自动在（一次性预配置窗口）同时并排中显示以下信息：
- 当前调用堆栈
- 最近更改的局部变量的值
- 加载的模块（DLL）
- 所有活动断点及其位置的列表
- 一个监视窗口，其中包含我输入的最后一个监视表达式
- 用于检查原始内存内容的内存窗口
- 显示当前寄存器值的小窗口
加/减一些功能，这也是我在 Linux 下的 Eclipse/CDT 下所期望的。 当使用 VIM、Emacs、gdb/DDD 等进行开发时，如何检索此工作流程和呈现的信息？
这个问题实际上并不是关于某个工具是否具有某个功能，而是关于了解开发/调试工作正在使用功能的组合，并且有多种触手可及的选项，以及您如何当不使用完全集成的 IDE 时访问此信息。
OK, so there are numerous questions around, asking for a "Visual Studio equivalent on Linux" or a variation of this question. (here, here, here, ...)
I would like to focus on one aspect and ask how the debugging workflow possibly differs on different systems, specifically the full-integrated-IDE approach used by Visual Studio (like) systems and a possibly more "separate" toolchain oriented approach.
To this end, let me present what I consider a short description of the "Visual Studio Debugging Workflow":
- Given an existing project
- I open up the project (one single step from a user perspective)
- I navigate to the code I want to debug (possibly by searching of my project files, which is simply done by opening the Find in Files dialog box.)
- I put a breakpoint at line (a), simply by putting the cursor on the line and hitting
F9 - I put a "tracepoint" at line (b), by adding a breakpoint there and then changing the breakpoint properties so that the debugger doesn't stop, but instead traces the value of a local variable.
- I hit
F5, which automatically compiles my executable, starts it under the debugger and then I wait until the prg stops at (a), meanwhile monitoring the trace window for output of (b) - When the debugger finally stops at (a), my screen automatically shows me the following information in (one-time preconfigured windows) side-by-side at the same time:
- Current call stack
- values of the most recently changed local variables
- loaded modules (DLLs)
- a list of all active breakpoints with their locations
- a watch window with the last watch expressions I entered
- A memory window to examine raw memory contents
- a small window displaying current register values
Plus/minus some features, this is what I would expect under Eclipse/CDT under Linux also.
How would this workflow and presented information be retrieved when developing with VIM, Emacs, gdb/DDD and the likes?
This question isn't really about if some tool has one feature or not, it's about seeing that development/debugging work is using a combination of features and having a multitude of options available at your fingertips and how you access this information when not using a fully integrated IDE.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为你的答案不仅在于你使用哪种软件，还在于你使用什么方法。我使用 Emacs 并依赖 TDD 进行大部分调试。当我看到某些事情失败时，我通常会编写测试来填补我（显然）错过的空白，并以这种方式检查每一个期望。所以我每次使用调试器之间的时间间隔很远。
当我遇到问题时，我有多种选择。在某些情况下，我首先使用 valgrind，它可以立即告诉我是否存在一些与内存相关的问题，从而无需调试器。它将直接指向我覆盖或删除应该保留的内存的行。如果我怀疑竞争条件 valgrind 非常擅长。
当我使用调试器时，我经常通过 GUD 模式直接在 emacs 中使用它。它将给我一个包含堆栈、局部变量、源代码、断点和一个可以命令调试器的窗口的视图。它通常涉及设置几个断点、观察一些内存或一些评估，以及单步执行代码。这与在 IDE 中使用调试器非常相似。 GDB 调试器是一个强大的野兽，但我的问题从来没有大到需要调用它的力量。
I think your answer isn't just about which software you use, but also what methodology you use. I use Emacs and depends on TDD for most of my debugging. When I see something fail, I usually write tests filling in the gap which I (obviously) have missed, and checks every expectation that way. So it goes far between each time I use the debugger.
When I do run into problems I have several options. In some cases I use valgrind first, it can tell me if there is some memory related problems right away, eliminating the need for the debugger. It will point straight to the line where i overwrite or delete memory that should be left alone. If I suspect a race condition valgrind is pretty good at that to.
When I use the debugger I often use it right in emacs, through GUD mode. It will give me a view with stack, local variables, the source code, breakpoints and a window where I can command the debugger. It usually involves setting a couple of breakpoints, watching some memory or some evaluation, and stepping through the code. It is pretty much like using the debugger in an IDE. The GDB debugger is a powerful beast, but my problems has never been large enough to need to invoke its power.