在发布模式下从 pdb 获取行号
调试器（或 CLR 异常处理程序）是否可以使用 pdb 显示在发布模式下发生异常的行？
发布模式下的代码经过优化，并不总是遵循“原始”代码的顺序和逻辑。
同样令人惊讶的是，即使在发布模式下，调试器也可以逐步浏览我的代码。 优化应该会让导航变得非常不舒服。
您能为我澄清这两点吗？
Is it possible for the debugger (or the CLR exception handler) to show the line where the exception happened in Release mode using the pdb?
The code, in release mode, is optimized and do not always follow the order and logic of the "original" code.
It's also surprising that the debugger can navigate through my code step by step, even in Release mode. The optimization should make the navigation very inconfortable.
Could you please clarify those two points for me?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我不太熟悉如何使用 CLR 完成此操作，但它可能与使用本机代码完成此操作非常相似。 当编译器生成机器指令时，它会向 pdb 添加条目，基本上表示“当前地址 X 处的指令来自 foo.cpp 中的第 25 行”。
调试器知道当前正在执行的程序地址。 因此，它在 pdb 中查找某个地址 X，发现它来自 foo.cpp 中的第 25 行。 使用它，它能够“单步执行”您的源代码。
无论调试还是发布模式，此过程都是相同的（前提是在发布模式下生成 pdb）。 然而，您是对的，由于优化，调试器通常在发布模式下不会“线性”地逐步执行代码。 它可能会意外地跳转到不同的行。 这是因为优化器改变了指令的顺序，但它不会改变地址到源代码行的映射，因此调试器仍然能够遵循它。
I'm not as familiar with how this is done with CLR, but it's probably very similar to how it's done with native code. When the compiler generates machine instructions, it adds entries to the pdb that basically say "the instruction at the current address, X, came from line 25 in foo.cpp".
The debugger knows what program address is currently executing. So it looks up some address, X, in the pdb and sees that it came from line 25 in foo.cpp. Using this, it's able to "step" through your source code.
This process is the same regardless of Debug or Release mode (provided that a pdb is generated at all in Release mode). You are right, however, that often in release mode due to optimizations the debugger won't step "linearly" through the code. It might jump around to different lines unexpectedly. This is due to the optimizer changing the order of instructions, but it doesn't change the address-to-source-line mapping, so the debugger is still able to follow it.
[@不确定]几乎是正确的。 编译器尽最大努力识别与当前机器代码指令紧密匹配的适当行号。
PDB 和调试器对优化一无所知； PDB 文件本质上将机器代码中的地址位置映射到源代码行号。 在优化的代码中，并不总是能够将汇编指令与特定的源代码行完全匹配，因此编译器会将其手头最接近的内容写入 PDB。 这可能是“之前的源代码行”，或“封闭上下文（循环等）的源代码行”或其他内容。
无论如何，调试器本质上会在 PDB 映射中找到最接近（如“之前或等于”）当前 IP（指令指针）的条目，并突出显示该行。
有时匹配不是很好，这时您会看到突出显示的区域到处乱跳。
[@Not Sure] has it almost right. The compiler makes a best effort at identifying an appropriate line number that closely matches the current machine code instruction.
The PDB and the debugger don't know anything about optimizations; the PDB file essentially maps address locations in the machine code to source code line numbers. In optimized code, it's not always possible to match exactly an assembly instruction to a specific line of source code, so the compiler will write to the PDB the closest thing it has at hand. This might be "the source code line before", or "the source code line of the enclosing context (loop, etc)" or something else.
Regardless, the debugger essentially finds the entry in the PDB map closest (as in "before or equal") to the current IP (Instruction Pointer) and highlights that line.
Sometimes the match is not very good, and that's when you see the highlighted area jumping all over the place.
调试器会尽力猜测问题发生的位置。 它不能保证 100% 准确，并且对于完全优化的代码，它通常会不准确 - 我发现不准确的范围从几行到完全错误的调用堆栈。
调试器对优化代码的准确程度实际上取决于代码本身以及您正在进行哪些优化。
The debugger makes a best-effort guess at where the problem occurred. It is not guaranteed to be 100% accurate, and with fully optimized code, it often will be inaccurate - I've found the inaccuracies ranging anywhere from a few lines off to having an entirely wrong call stack.
How accurate the debugger is with optimized code really depends on the code itself and which optimizations you're making.
参考以下SO问题：
显示行发布模式下 .NET 程序集的堆栈跟踪中的数字
Reference the following SO question:
Display lines number in stack trace for .NET assembly in release mode