The PDB file that results from linking results in a PDB file that cannot be processed.
Here is the build chain:
AS: \masm32\bin\ml.exe /c /Zi /coff /DEBUG
LD: \masm32\bin\link.exe /DEBUG /SUBSYSTEM:CONSOLE
Here are the versions:
Microsoft (R) Macro Assembler Version 6.14.8444
Microsoft (R) Incremental Linker Version 5.12.8078
This is a single 32-bit program built with a single assembly file and a single object.
This is the evidence:
Ghidra 11.0.3: ghidra.app.util.bin.format.pdb2.pdbreader.PdbException: Unknown TPI Version: 2
IDA 8.4: Failed to load [...] Input file has an unsupported signature: Microsoft C/C++ program database 2.00.
Can anyone give me a lead here on how to investigate? Or is this a symptom of a known problem with perhaps the linker?
Here is a zip archive with all of the intermediaries and the Makefile used to compile.
MD5 sum: 77c1b7a11d0112d313882ddf269f02a3
There are 6 files: Makefile hello.asm hello.exe hello.ilk hello.obj hello.pdb
RESOLUTION:
The included linker in MASM32 SDK is too old to generate a PDB file that can be correctly parsed by the two tools, Ghidra and IDA Pro.
From the included Makefile in the attachment, all that was needed was: (with VS2022 installed)
LD=\masm32\bin\link.exe => LD=X:\"Program Files"\"Microsoft Visual Studio"\2022\Community\VC\Tools\MSVC\14.40.33807\bin\Hostx86\x86\link.exe
Note that because I am using
What versions of ml.exe and link.exe are you using?
And what is your programming environment? Are you using Visual Studio?
32-bit program? 64-bit?
Quote from: sudoku on May 24, 2024, 08:52:17 AMWhat versions of ml.exe and link.exe are you using?
And what is your programming environment? Are you using Visual Studio?
Sorry, I should have included this information. I'll reply here and update on the original post if I can.
I had installed masm via the website earlier that day.
Microsoft (R) Macro Assembler Version 6.14.8444
Microsoft (R) Incremental Linker Version 5.12.8078
My programming environment is with a text editor and a terminal. I'm using MinTTY specifically, though it should not matter I believe since I am using the full path to execute both ml and link.
Quote from: NoCforMe on May 24, 2024, 09:34:58 AM32-bit program? 64-bit?
This is a 32-bit program.
okay, so you do have the Masm32 SDK installed. :thumbsup: Does your program assemble and link properly otherwise? Could you post your project as an attachment?
So a pdb file is generated but ghidra and ida do not recognize it?
Have you tried ollydbg?
Have you successfully generated pdb files in the past?
I am unfamiliar myself with all the command line switches needed for creating a useful pdb file, but other members here use them (pdb files) often. Could you be missing something in the switches?
Could it be a "/DEBUGTYPE:xxxx" switch or lack thereof issue?
With all of the very knowledgeable members here, I am surprised no one else has replied, offering assistance :sad: I am thinking that it must be something simple, but because of my lacking knowledge of .pdb files I do not know what it might be.
Quote from: sudoku on May 25, 2024, 01:35:59 AMokay, so you do have the Masm32 SDK installed. :thumbsup: Does your program assemble and link properly otherwise? Could you post your project as an attachment?
So a pdb file is generated but ghidra and ida do not recognize it?
Have you tried ollydbg?
Have you successfully generated pdb files in the past?
I am unfamiliar myself with all the command line switches needed for creating a useful pdb file, but other members here use them often. Could you be missing something in the switches?
1. The program assembles, links, and executes.
2. A PDB file is generated, yes, and both Ghidra and IDA do not recognize it.
3. When I work with C projects in Windows, I can usually just generate them at the compilation phase, since it automatically assembles and links for me with `cl.exe /Zi`. I haven't gotten MASM to work though.
4. I *might* be missing some flags. I'm not sure though.
5. I'm not sure if OllyDbg is useful here. The execution is fine, and I can generate a good disassembly from either tools. However, the disassembly is missing the symbols, which would be available from the PDB.
6. Here is a link to a zipped Hello World project that has the same problem. The link expires in 24 hours or 100 downloads--whichever comes first: https://wormhole.app/eLYvL#1XZvDVaTT54_9mwohJ1bDQ
Note, I have added all of the intermediary files that are produced with the options I have provided. The Makefile includes exactly what I have done to assemble/link. To replicate my steps, just do a simple `make clean` and then a `make`.
MD5SUM of zip archive: 77c1b7a11d0112d313882ddf269f02a3
Should contain 6 files:
Makefile hello.asm hello.exe hello.ilk hello.obj hello.pdb
EDIT: I attached the zip to the original post.
If your project contains a resource file:
RC.EXE /v "Hello.rc"
ML.EXE /c /coff /Cp /Zi /Zd /nologo /I"X:\MASM32\Include" "Hello.asm"
LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /PDB:"Hello.pdb" /VERSION:4.0 /LIBPATH:"X:\MASM32\Lib" /OUT:"Hello.exe" "Hello.obj" "Hello.res"
If your project doesn't contain a resource file:
ML.EXE /c /coff /Cp /Zi /Zd /nologo /I"X:\MASM32\Include" "Hello.asm"
LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /PDB:"Hello.pdb" /VERSION:4.0 /LIBPATH:"X:\MASM32\Lib" /OUT:"Hello.exe" "Hello.obj"
Where X: is the drive letter where your MASM32 SDK includes files are located, replace with the appropriate drive letter for your installation, or modify the path for your installed location.
You may need to replace the older resource compiler and linker with one from a visual studio installation for it generate the appropriate pdb file to be recognized by debuggers - the older version pdb that is generated by the the older linker wont be recognized. I recommend linker version 12 or higher.
Okay, I have downloaded it and made a batch file for the program rather than using the makefile. I added the /Zd switch.
The batch file contents:
\masm32\bin\ml.exe /c /Zi /Zd /coff /DEBUG hello.asm
\masm32\bin\link.exe /DEBUG /SUBSYSTEM:CONSOLE hello.obj
It works in ollydbg and I can see the symbols.
(https://i.postimg.cc/MZsSgcMB/untitled.png)
Thank you fearless for your assistance to our new friend. :thumbsup:
If your looking to replace the resource compiler and linker (and lib) with newer ones from a visual studio installation you probably need the following files:
Note these where from an earlier visual studio installation (vs 2012 I think), so newer ones may require more files and/or similarly names files from the ones listed:
cvtres.exe
cvtres.exe.config
dumpbin.exe
editbin.exe
lib.exe
link.exe
link.exe.config
msobj120.dll
mspdb120.dll
mspdbcore.dll
mspdbsrv.exe
mspdbst.dll
msvcr120.dll
rc.exe
rcdll.dll
Quote from: fearless on May 25, 2024, 02:21:06 AMIf your project contains a resource file:
RC.EXE /v "Hello.rc"
ML.EXE /c /coff /Cp /Zi /Zd /nologo /I"X:\MASM32\Include" "Hello.asm"
LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /PDB:"Hello.pdb" /VERSION:4.0 /LIBPATH:"X:\MASM32\Lib" /OUT:"Hello.exe" "Hello.obj" "Hello.res"
If your project doesn't contain a resource file:
ML.EXE /c /coff /Cp /Zi /Zd /nologo /I"X:\MASM32\Include" "Hello.asm"
LINK.EXE /SUBSYSTEM:WINDOWS /DEBUG /DEBUGTYPE:CV /PDB:"Hello.pdb" /VERSION:4.0 /LIBPATH:"X:\MASM32\Lib" /OUT:"Hello.exe" "Hello.obj"
Where X: is the drive letter where your MASM32 SDK includes files are located, replace with the appropriate drive letter for your installation, or modify the path for your installed location.
You may need to replace the older resource compiler and linker with one from a visual studio installation for it generate the appropriate pdb file to be recognized by debuggers - the older version pdb that is generated by the the older linker wont be recognized. I recommend linker version 12 or higher.
AH, using linker version 14.40.33808.0 solved everything! I guess the PDB version was just too low to be correctly parsed by the disassemblers.
Quote from: sudoku on May 25, 2024, 02:23:08 AMOkay, I have downloaded it and made a batch file for the program rather than using the makefile. I added the /Zd switch.
The batch file contents:
\masm32\bin\ml.exe /c /Zi /Zd /coff /DEBUG hello.asm
\masm32\bin\link.exe /DEBUG /SUBSYSTEM:CONSOLE hello.obj
File is attached below...
Use the batch file and see if it changes anything for you.
It works in ollydbg and I can see the symbols.
(https://i.postimg.cc/MZsSgcMB/untitled.png)
Unfortunately, same error with your script as well.
Ok. So then you are all sorted here?
Thanks fearless.
Thank you both for the resolution. Turns out @sudoku was right--it was a simple fix. I'll update the main thread with the resolution as well.
Glad to be of limited assistance. :smiley:
BTW, I noticed something: you had a /DEBUG switch on the ml.exe command line, which is not a valid option. Dunno if this had any effect or not, but it shouldn't be there.
Quote from: NoCforMe on May 25, 2024, 04:40:15 AM... you had a /DEBUG switch on the ml.exe command line...
:dazzled: I totally missed that myself. It did assemble though, so most likely it was ignored by ml.
Quote from: poultrysci on May 25, 2024, 02:41:52 AMAH, using linker version 14.40.33808.0 solved everything! I guess the PDB version was just too low to be correctly parsed by the disassemblers.
That's a bit odd; I'm using linker version 5.12.8078 and I've never had any problems with .PDB files. I use OllyDbg though.
Have you tried Olly? It's a very good debugging tool.
Quote from: NoCforMe on May 25, 2024, 05:27:52 AMThat's a bit odd; I'm using linker version 5.12.8078 and I've never had any problems with .PDB files. I use OllyDbg though.
Have you tried Olly? It's a very good debugging tool.
I have also suggested ollydbg. Ida is overkill, imo. Not sure about ghidra, never used it. Also I don't trust anything (ghidra) supposedly offered up by the NSA of all entities. NSA on GitHub - ghidra (https://github.com/NationalSecurityAgency/ghidra). You gotta ask yourself, what is the NSA's motive?
The Answer (https://fedscoop.com/nsa-now-sharing-bunch-code-github/) I had to look it up... not trying to promote any conspiracy theories, but I do find it rather odd.
Oh yeah, nothing at all suspicious about the NSA, for chrissakes, posting code for us to use, eh? I'd sooner use anything posted by some QAnon jerk ... no thanks.
Where is Ed Snowden when we need him?
Re: ghidra
I had missed sinsi's post here: https://masm32.com/board/index.php?topic=7924.0 (https://masm32.com/board/index.php?topic=7924.0). I came across it today.