追踪哪个依赖项包含 SSE 指令
我们的一位客户需要在没有 SSE 的情况下构建我们的程序，因为他使用的是相当旧的硬件。我的问题是，即使我全面修改我们的项目设置以取消所有库和应用程序的 SSE 设置。二进制文件中似乎仍然存在依赖项，该依赖项是使用 SSE 指令编译的，导致应用程序崩溃。
我的问题是：有没有办法获取二进制文件或库并检测它是否包含特定版本 SSE 的 SSE 指令？
我们使用的是 VS，语言是 C++，因此任何适用于该工具集的工具都会很棒。
One of our customers needs a build of our program without SSE as he's on quite old hardware. My problem is that even if I modify our project settings across the board to unset SSE for all libraries & binaries it would seem there's still a dependency somewhere which is compiled with SSE instructions on, causing the application to crash.
My questions is: Is there a way to take a binary or library and detect if it contains SSE instructions of a specific version of SSE or not?
We're using VS and the language is C++, so any tool applicable to that toolset would be terrific.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
反汇编所有涉及的二进制文件，然后在反汇编中搜索 SSE 指令助记符。
Disassemble all involved binaries, then do a search for SSE instruction mnemonics in the disassemblies.
由于您已经在编译器中关闭了 SSE 指令生成，因此问题出在静态库之一上。要缩小范围，基本上有两种方法：
在“0x635de077”...。您使用该地址并查看映射文件以查看它属于哪个函数。或者，您可以在调试器中运行该程序。当程序崩溃时，调试器会显示程序停止的位置。
编辑：反汇编 .lib 文件的另一种方法是使用附带的 DUMPBIN 实用程序与视觉工作室。另外，STATUS_ACCESS_DENIED 建议的小型转储方法是一个好主意。
Since you have already turned off the SSE instruction generation in the compiler, the problem is in one of the static libraries. To narrow it down, basically you have 2 ways go:
at "0x635de077".... You use that address and look at the map file to see in which function it belongs. Alternatively, you can run the program inside a debugger. When program crashes, the debugger shows you where program has stopped.
edit: Another method to get a disassembly of a .lib files is to use the DUMPBIN utility that comes with Visual Studio. Also, the minidump method suggested by STATUS_ACCESS_DENIED is an excellent idea.
使用此处所述的方法从客户处获取小型转储文件。即让客户运行您的构建。一旦崩溃，应该创建一个小型转储文件，您可以使用它（事后分析）来准确分析崩溃的位置。它与调试符号（和/或映射文件）一起，实际上会告诉您造成严重破坏的确切库。
这归结为 AlefSin 建议的解决方案中的第 2 点。但是，客户不必运行调试器。对于内核模式驱动程序，这通常甚至是获取有关问题的有意义信息的唯一方法。不过，用户模式代码也存在相同的功能。使用它。
Use a method as described here in order to get a minidump file from the customer. I.e. have the customer run your build. Once it crashes a minidump file should be created and you can use it - post-mortem - to analyze exactly where it crashed. Which, together with the debug symbols (and/or map file), will actually tell you the exact library that caused havoc.
It boils down to point 2 in the solution suggested by AlefSin. However, the customer will not have to run a debugger. For kernel mode drivers this is usually even the only means to get meaningful information about problems. The same facility exists for user mode code, though. Use it.