Summary: A VS2015 solution with mixed C and Assembler, does not display symbols in assembler code when debugging after upgrading to VS2017 or VS2019). [Oct 2109: problem solved, see note at end].
Long details:
I have a VS 2015 xxx.sln with 32 bit C code compiled by the VS 2015 compiler, with a large 32 bit assembler code parlanse0.asm assembled by a custom command line:
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
I'm not sure this is relevant, but here's the Linker options:
/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
[If this is the linker command line, where does it get the names of the .obj files it processes?]
This solution compiles/builds/runs fine under VS 2015.
I'm trying to upgrade to VS 2017 (update: Sept 2019, problem never resolved, so I just tried it again with VS 2019... same problem).
The upgrade seemed trivial: I simply started VS 2017 and pointed it at the VS 2015 solution file. Apparently nothing changes, at least my source control (over the various MS build files like .sln don't see any changes). Magically, almost everything works: I can compile/run/debug the application.
However, the assembly source code is no longer visible when I'm in the debugger and attempt to "go to source code" when I've stepped into a bit of assembler. "Goto source code" from the assembler works fine in VS 2015. Likewise, if during debugging I choose an assmbley language source line and attempt to "Go to disassembly" I get a pop-up window "Disassembly cannot be displayed... there is no executable code associated with this location", and that's clearly wrong. Also behavior that was find under VS 2015.
What do I have to change? Are there documents somewhere that describe what is different?
[Addition: The assembler source is in a different directory than the .C sources. This causes the .sbr file for the assembler code to be produced in a different directory from the .sbr files for the C code. Apparently the assembler code .sbr is not picked up the build process; in one of the log files I can see all the .sbr files for the C code but not for the assembler. So this doesn't look right. However, my understanding is .sbr files support VisualStudio tag lookup, not object-location-to-source-line map so I think this is a red herring. Where is the object-location-to-source-line map produced? Does the linker do it?]
[Addition: following the advice in the comments to look at another answer, I changed the /DEBUG option to /DEBUG:FULL with no apparent effect on the problem.]
[I found some article on PDB files, and how the C++ compiler "updates" it as is compiles individual .cpp (.c?) files. Is MASM supposed to generate a PDB files? So... how would MASM update the compiler's target PDB file?]
... added after 2 month delay ...
I see this in a disassembly window on my assembler code:
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:
These are my symbols, so they are clearly getting to the debugger. I ask the disassembly window to show line numbers... it does nothing. So somehow the symbols are getting through, but not the line number information or maybe not the source file location. Thoughts?
EDIT: October 9, 2019: PROBLEM CLAIMED SOLVED. A long interaction with Microsoft got them to agree this is a problem in the debugger. I verified that VS 2015 Update 1 was the last version that worked properly; VS 2015 Update 2 and later, VS 2017 and VS 2019 all suffer from the same problem. MS has told me that they have identified the problem and a fix will be available in VS 2019 v16.4 Public Release in December 2019.