Question

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

parlanse0.asm Property Pages

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

我不确定这是否相关，但这是链接器选项：

/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.升级似乎微不足道：我只是启动VS 2017并将其指向VS 2015解决方案文件。显然地没有任何变化，至少我的源代码控制（在.sln等各种MS构建文件上看不到任何变化）。奇怪的是，几乎所有东西都可以工作：我可以编译/运行/调试应用程序。

然而，当我在调试器中时，组装源代码不再可见，并且当我进入一些汇编程序时尝试“转到源代码”。来自汇编程序的“转到源代码”在VS 2015中工作正常。同样，如果在调试期间我选择了一个混合语言源代码行并尝试“转到反汇编”，我会弹出一个窗口“无法显示反汇编...那里没有与此位置相关联的可执行代码“，这显然是错误的。也是在VS 2015下找到的行为。

我需要改变什么？是否有某些文件描述了哪些不同？

[补充：汇编源与.C源位于不同的目录中。这会导致汇编代码的.sbr文件在与C代码的.sbr文件不同的目录中生成。显然，汇编程序代码.sbr没有被选中构建过程;在其中一个日志文件中，我可以看到C代码的所有.sbr文件，但不能看到汇编程序。所以这看起来不对。但是，我的理解是.sbr文件支持VisualStudio标签查找，而不是对象位置到源线图，所以我认为这是一个红色的鲱鱼。物体位置到源线图在哪里生成？链接器是否这样做？]

[补充：按照评论中的建议查看另一个答案，我将/ DEBUG选项更改为/ DEBUG：FULL，对问题没有明显影响。]

[我发现了一些关于PDB文件的文章，以及C ++编译器如何“更新”它，因为它编译了单独的.cpp（.c？）文件。 MASM应该生成PDB文件吗？那么...... MASM如何更新编译器的目标PDB文件？]

......延迟2个月后加入......

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

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:

这些是我的符号，因此他们显然已进入调试器。我要求反汇编窗口显示行号...它什么都不做。因此，某些符号正在通过，但不是行号信息，也可能不是源文件位置。想法？

Answer 1

有调试信息（在 pdb 文件中）需要2个步骤：

编译器必须包含针对ml [64]的obj文件的调试信息编译器这是/Zd选项
链接器在命令行中必须具有/DEBUG选项。在这种情况下获取调试信息（存储在 obj / lib 文件的.debug$S部分）和创建 pdb 文件

如果编译器和链接器的命令行都正确（有这个选项）需要按以下顺序检查：

查看任何文本/二进制查看器中的 .obj 文件 - 是完整路径字符串文件中存在asm文件名。只需搜索文件中的PARLANSE0.ASM（或您的源文件如何命名）（全部存储为ansi纯文本的名称） - 找到此名称是路径是正确的？如果是 - 这意味着编译器（在我们的情况下为ml）正确，我们可以继续前进）
查看 pdb 文件 - 此处是否存在此字符串？
查看 exe 文件 - 搜索.pdb - 完整（且正确）路径您的 pdb 是否存在于 exe 文件中？再次它存储为普通的ansi 文本
尝试使用替代调试器 - 我建议windbg - 他能吗？去找货源。为了方便检查你甚至可以特别临时 build - 在转到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）。但是，您可以构建没有任何问题，因为之前编译过文件。

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

2 个答案: