Display the source of problems is when I use include files.
What I tried: GoVest, VS debug, WinDbg
my bat file
c:\masm32\bin\ml /c /coff /ZI /Zd /Fl%file%.lst %file%.asm
c:\masm32\bin\Link /SUBSYSTEM:WINDOWS /DEBUG %file%.obj resource.obj /MAP
you should probably add /PDB:myfile.pdb to your LINK line, and see if it changes anything
I tried, and even tried other linker too. (polink).
pdb file is not included in the text "source.inc".
Obj file, the text is found. The EXE was not.
If /Zd or /Zi are included on the ML command line then debug object records will be added to the the resulting object file. If /DEBUG is included on the LINK command line a PDB file will be created (defaults to image name if /PDB:# is not specified). The generated EXE will have the necessary information that the debugger will retrieve to load the debug records. If the debugger can not locate the PDB file check the location of the PDB file (should be in the same directory as the EXE/DLL/OCX file). I hever has a problem with VS Debug locating a PDB as long as the PDB exists in the correct location.
PDB file generated.
But only found "xxx.asm" string. "xxx.inc" string not found.
I think the pdb file generation is not good.
The debugger follows the line number, but not file xxx.inc, always shows xxx.asm
Go mad.
If you compile the visual studio
It is not always the xxx.asm file shows , but always show the include. (But it is good)
You tested it?
What debugger you use?
Nobody knows how, as source level debug?
VS debug does not debug INC files because ML does not generate debug records that will reference the INC file. .Though code can be included in an INC file normally the file will contain structures, typedefs and constants. The MASM32 assembler does not generate debug records with references to instructions that do no generate code (either data or executable). The C++ compiler generates a more extensive range of debug records which can include refrences to H files and can also produce what you are probably refering to as a "Browser database". A browser database is a product of the Visual Studio environment and can be thought of as a seperate program. The "Browser database" is not a product of a code generator or linker. Since Microcrap never integrated MASM into the Visual Studio environment, the browser is useless for ASM files.
ML will generate debug records for constants structs and unions but not reference back to the source code that defined them. Therefore the "reference search" will not "link" back to the source code.
latest masm (ml v10.00.20506.01) generates "Source Files" debug info correctly, with full path!
I know how to download: ml v10.00.20506.01?
Quote from: korte on August 21, 2009, 11:27:59 AM
I know how to download: ml v10.00.20506.01?
You probably don't need Masm v10. AFAIK Masm's debug information was changed in version 7, from "Codeview 4" to "Codeview 7" (or 8?), and since then it also includes full source paths.
So it should suffice to download Masm v8:
http://www.microsoft.com/downloads/details.aspx?FamilyId=7A1C9DA0-0510-44A2-B042-7EF370530C64&displaylang=en
Here's the deal:
debug information compiled from older version of masm (ML < 7.0) wont work correctly with newer linker versions, one of the symptoms is incomplete path and in case of combining ML615 and LINK900 no path at all !! :) .
if you are going to use older ML (614 v615) use older linkers (v512 v600)
if you are going to use newer ML >= 700 use the coresponding newer linker
This is only relevant for /DEBUG builds.
ML v10:
http://go.microsoft.com/fwlink/?LinkId=151365
check out this thread:
http://www.masm32.com/board/index.php?topic=11599.0