断点不会仅使用VS2013 / WEC2013在C ++文件的一个方法中设置 [英] Breakpoint will not set in only one method of C++ file using VS2013 / WEC2013

问题描述

我正在调查MS EHCI MDD驱动程序的问题/修复。 我已将ehcdmdd.lib项目克隆到我的BSP /平台中，并在那里构建更改。 我的BSP已经构建了一个具有PDD层并链接到ehcdmdd.lib的DLL，现在是
，我的更改链接到我的替换副本。 一切都很好，它构建并且我可以运行此代码并且我的修改生效。

I am investigating an issue/fix to the MS EHCI MDD driver.  I have cloned the ehcdmdd.lib project into my BSP/Platform and am building changes to it there.  My BSP already builds a DLL that has the PDD layer and links to the ehcdmdd.lib, and now with my changes links to my substituted copy.  All is good, it builds and I can run this code and my modifications take effect.

唯一的问题是，一个文件中有一个方法（cpipe.cpp中的CQueuedPipe :: IssueTransfer） ）调试器拒绝设置断点的地方。 其他文件都可以，同一文件中的其他方法都可以，包括我添加的新文件。

The only problem is, there is one method in one file (CQueuedPipe::IssueTransfer in cpipe.cpp) where the debugger refuses to set a breakpoint.  Other files are OK, and other methods in the same file are OK, including new one's I've added.

在成功的位置添加断点时我看到的行为是你点击F9，你短暂（3-4秒）在断点窗口看到'[pending]'，直到调试器可以运行它的断点实例化器，然后断点变为红色。 
类似于删除断点，除了你看到'[删除待定]'。这是每个人都看到的，因为这是正常操作。

The behavior I see when adding a breakpoint in a location that is successful is when you hit F9, you briefly (3-4 seconds) see '[pending]' in the breakpoint window until the debugger can run its breakpoint instantiator, then the breakpoint goes solid red.  Similar for removing breakpoints, except you see '[delete pending]'. This is what everybody sees as this is normal operation.

在问题的情况下，当你设置断点时，你永远不会看到'[pending]'。  ;断点指标仅与轮廓圆保持一致。 删除此断点显示'[delete pending]'。

In the problem case, you never see '[pending]' when you set the breakpoint.  The breakpoint indicator stays with just the outline circle.  Removing this breakpoint DOES show '[delete pending]'.

调试器似乎确实知道哪些行是源，哪些是问题例程中的代码 - 尝试在注释上设置断点例如，将生成'断点将继续下一行代码'消息 - 但这只会导致相同的
不良行为。

The debugger does seem to know which lines are source and which are code in the problem routine - trying to set a breakpoint on a comment for example will generate the 'breakpoint will go on next line of code' message - but this just results in the same bad behavior.

有趣的是，我可以设置一个断点从IssueTransfer调用子程序，然后从子程序返回（例如F11）并继续单步执行IssueTransfer例程。 这证实我有正确的源文件等。 但我还是
无法设置断点！

Interestingly, I can set a breakpoint in a subroutine call from IssueTransfer, and then return from subroutine (e.g. F11) and continue stepping through the IssueTransfer routine.  This confirms that I have the right source file, etc.  But I still can't set a breakpoint!

我已经尝试了一切我能想到的解决方法，包括：

I have tried everything I can think of to work around this, including:

- 清理构建，手动擦除.pdb文件，解决.sdf文件。 重新启动VS2013。

- clean builds, manually wiping .pdb files, solution .sdf file.  Restarting VS2013.

- 将文件重命名为唯一的（cpipe.cpp - > cpipe2.cpp）。 将类名重新定义为新名称。

- renaming the file to something unique (cpipe.cpp -> cpipe2.cpp).  Redefining the class name to a new name.

- 在编译/链接过程中查找会以某种方式使此例程"特殊"的任何内容，以便它会触发此行为。

- look for anything in the compile/link process that would somehow make this routine 'special' such that it would trigger this behavior.

有没有人见过这个？ 有没有人对什么寻找或检查或尝试什么有任何建议？

Has anyone seen this?  Does anyone have any suggestions for what to look for or check for or something to try?

VS版本12.0.40629.00更新5. Platform Builder 8.00（6247）。 目标是ARM CPU。

VS version 12.0.40629.00 Update 5. Platform Builder 8.00 (6247).  Target is ARM CPU.

谢谢，

Wil

推荐答案

也许是个愚蠢的问题：你关闭了任何优化吗？

Maybe stupid question: did you switched off any optimization?

您是否尝试通过反汇编视图进行调试？例如，在调用此方法之前放置断点，切换到反汇编程序模式并查看调用此方法时发生的情况。

And did you try to debug via disassembly view? For example, place breakpoint before calling this method, switch to disassembler mode and see what is happening while calling this method.

这篇关于断点不会仅使用VS2013 / WEC2013在C ++文件的一个方法中设置的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！