如何将Win32 C+ MASM“解决方案”从Visual 2015升级到VS 2017/2019

Question

摘要:使用混合C和汇编程序的VS2015解决方案在升级到VS2017或VS2019后调试时不会在汇编程序代码中显示符号)。109年10月:问题解决了，见尾注。

详细资料：

我有一个由VS 2015编译器编译的带有32位C代码的VS 2015 xxx.sln，其中有一个大型32位汇编程序代码parlanse0.asm由自定义命令行组装：

parlanse0.asm属性页

Item Type:   Custom Build Tool

Command Line: ml /D SANITYCHECKS="1" /D EVENTBUFFERENABLE="1" /D TESTING="1" /D PROFILE="0"  /Sg /Sl132 /Sx /Zd /Zi /c /Cx /coff /Zd /Fl "%(FullPath)"
Outputs: parlanse0.obj;%(Outputs)
Additional Dependencies:  <list of MASM include file>
Link Objects:  Yes
Treat Output As Content: No

我不确定这是否相关，但下面是Linker选项：

/OUT:"Debug\run.exe" /MANIFEST /PROFILE /NXCOMPAT:NO /PDB:"Debug/erun.pdb" /DYNAMICBASE:NO "odbc32.lib" "odbccp32.lib" "netapi32.lib" "iphlpapi.lib" "psapi.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" /LARGEADDRESSAWARE /MACHINE:X86 /SAFESEH:NO /INCREMENTAL:NO /PGD:".\Debug\run.pgd" /SUBSYSTEM:CONSOLE",5.01" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:".\Debug\run.exe.intermediate.manifest" /MAP":.\Debug/run.map" /ORDER:@"RTSCFunctionOrder.txt" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\Microsoft Platform SDK\Lib" /DELAYLOAD:"iphlpapi.dll" /DELAYLOAD:"comdlg32.dll" /TLBID:1 

如果这是链接器命令行，它在哪里获得它处理的.obj文件的名称？

此解决方案在VS 2015下编译/构建/运行良好。

我试图升级到VS 2017 (更新:2019年9月，问题从未解决，所以我只是再次尝试了VS 2019年.同样的问题)。

升级似乎微不足道:我只是从VS 2017开始，并将其指向VS 2015解决方案文件。显然没有什么变化，至少我的源代码控制(对于各种MS构建文件，比如.sln，没有看到任何更改)。神奇的是，几乎所有东西都能工作:我可以编译/运行/调试应用程序。

但是，当我在调试器中尝试“转到源代码”时，当我进入汇编程序时，程序集源代码就不再可见了。汇编程序中的"Goto源代码“在VS 2015中运行良好。同样，如果在调试期间，我选择assmbley语言源代码行并尝试“去反汇编”，我得到一个弹出窗口“无法显示反汇编.没有与此位置相关的可执行代码”，这显然是错误的。也是在VS 2015下发现的行为。

我要换什么？有什么地方的文档描述了什么是不同的？

添加:汇编程序源位于与.C源不同的目录中。这将导致汇编程序代码的.sbr文件在与C代码的.sbr文件不同的目录中生成。显然，汇编程序代码.sbr并没有捕获构建过程；在其中一个日志文件中，我可以看到C代码的所有.sbr文件，而不是汇编程序的。所以这看起来不太对。然而，我的理解是.sbr文件支持VisualStudio标签查找，而不是对象定位到源线地图，所以我认为这是一种红鲱鱼。目标位置到源线的地图是在哪里产生的？链接器做的吗？

添加:按照注释中的建议查看另一个答案，我将/DEBUG选项更改为/DEBUG:FULL，对问题没有明显的影响。

我找到了一些关于PDB文件的文章，以及C++编译器如何“更新”它作为编译单个.cpp (.c?)文件。MASM应该生成PDB文件吗？所以..。MASM将如何更新编译器的目标PDB文件？

..。在延迟两个月之后..。

我在汇编程序代码的反汇编窗口中看到了这一点：

00480107 CC                   int         3  
00480108 CC                   int         3  
RTSAllocate11D_end:
00480109 8D A4 24 00 00 00 00 lea         esp,[esp]  
00480110 8D A4 24 00 00 00 00 lea         esp,[esp]  
00480117 8D A4 24 00 00 00 00 lea         esp,[esp]  
0048011E 8D A4 24 00 00 00 00 lea         esp,[esp]  
00480125 8D A4 24 00 00 00 00 lea         esp,[esp]  
0048012C 8D A4 24 00 00 00 00 lea         esp,[esp]  
00480133 8D A4 24 00 00 00 00 lea         esp,[esp]  
0048013A 8D 9B 00 00 00 00    lea         ebx,[ebx]  
allocate_2to1E_bytes:

这些都是我的符号，所以它们很明显地到达了调试器。我让拆卸窗口显示线号..。它什么都不做。因此，符号正在传递，但不是行号信息，也可能不是源文件位置。有什么想法？

编辑:2019年10月9日：问题被解决了。与微软的长时间互动让他们同意这是调试器中的一个问题。我证实VS 2015 Update 1是最后一个正常工作的版本；VS 2015 Update 2及更高版本、VS 2017和VS 2019都面临同样的问题。MS告诉我，他们已经确定了问题所在，并将于2019年12月在VS 2019 v16.4公开发行版中提供修复。

Answer 1

要获得调试信息(在pdb文件中)，需要两个步骤：

• 编译器必须包括对ml64编译器obj文件的调试信息--这是/Zd选项
• 链接器必须在命令行中具有/DEBUG选项。在本例中，它获取调试信息(存储在obj / lib文件的.debug$S部分)并创建pdb文件。

如果编译器和链接器的命令行都正确(有此选项)，则需要按以下顺序签入：

1. 查看任何文本/二进制查看器中的.obj文件-都是文件中存在的源asm文件名的完整路径字符串。只需按原样在文件中搜索PARLANSE0.ASM (或如何命名源文件)(所有以ansi纯文本形式存储的名称)--找到这个名称了吗?路径正确吗？如果是，这意味着编译器(ml在我们的例子中是正确的，我们可以继续前进)
2. 查看pdb文件-这个字符串在这里也存在吗？
3. 查看exe文件-搜索.pdb -是否完整(并正确)路径为您的pdb存在于exe文件中？同样，它存储为纯正的ansi文本。
4. 尝试使用替代调试器--我建议风车 --他是否可以转到源代码。为了便于检查，您甚至可以在转到asm代码(或直接使用某些asm过程)并在exe开始时调用此过程之前，创建特殊的临时构建设置断点。即使这种逻辑“不正确”--我们只需要检查--都是调试器理解pdb格式的，并且可以显示asm的源代码。

如果windbg可以转到asm源代码，这意味着集成的vs2017调试器会出现一些问题。如果windbg不能-生成pdb格式的一些问题

Answer 2

将程序集文件名P.asm更改为parlanse0.asm，或将/Fo parlanse0.obj添加到自定义构建脚本的开头。

您不能通过您的文件生成parlanse0.obj和调试相关文件(parlanse0.iobj、parlanse0.ipdb)。但是，您可以构建没有任何问题，因为文件是以前编译的。