Visual studio 2017 changed the obj's debug info format. So the linker gives me "Warning LNK4209: debugging information corrupt,...." on every obj created by HJWASm/UASM.
Any chance the Uasm will support the new debug format in a near future?
VS 2017 Preview 3 suppose to solve this, but I can not confirm it. Still it would be nice to support the new format.
Regards,
Leaeaxedx
BTW: Great work with Uasm, hope you will keep its support for many years. :t
Hi,
most likely the reason is in other parameters. Give an example of your project that causes this error. I could not find any information about updating :icon_confused:
Information from Microsoft about the PDB format https://github.com/Microsoft/microsoft-pdb
Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
Hi,
Apparently the latest update of 2017 was supposed to solve this but it didn't work for me.
What i did find however is the solution depends on which version of link you try and use, for me the logical one wasn't right, (I had assumed HostX64) and instead I need to use this link version:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.10.25017\bin\HostX86\x64\link.exe"
This version doesn't produce the PDB error.
Thanks for your replies.
On Microsoft Visual studio Developer Community site this I got as the reply on the same issue:
-------------------------------------------
Solution by Lars Wood29. 9. 2017 01:42:00
The reason this happens is that Microsoft changed the format of the debug information created when building a .obj file in this release and so if you have .asm files, for example, that were built with an old version of masm, for example, or if these object files or likewise were built with the old format using some other tool presumably and in any event are part of a library then the linker generates this error. so for example if this file, in the example below, is built with an older masm and the object file then becomes part of a library, when the library is linked into an .exe or .dll file you get the link error (but not before you link into a .dll or .exe).
..\masm611\bin\ml /Zi /Zf /Zd /coff /c /Fo "%(Filename)"_dbg_info.obj "%(FullPath)"
by removing switches that create .obj debug info the problem goes away. Reassemble, rebuild the library and re-link application.
..\masm611\bin\ml /coff /c /Fo "%(Filename)"_no_dbg_info.obj "%(FullPath)"
In summary, the problem is the old debug info format that goes into a .obj file is not compatible with the new .obj debug info format. The .obj files with the incompatible debug format lurk inside library files. The problem only presents itself when the library file is linked into an application. The solution is to rebuild the .obj file and then relink the library and then link the application into a .exe or .dll etc. If you are linking against an old library file an incompatible .obj may be lurking within it. Either update to the most resent library files or if the library files are your own rebuild with up to date compiler or assembler generating the new .obj debug info format. If you are using an old assembler simply turning off the switches that build the .obj with the incompatible debug information will fix the problem. No error or warning is given until you link the library containing the incompatible .obj debug into a .dll or .exe file. The problem is in the .obj files with bad debug info, disabling debug info generation when building the .obj with the older compiler or assembler also solves the problem. I doubt that Microsoft will change or fix this (the complexity required is not worth it) since it would mean they would need to support two .obj debug info formats, i.e. the old format and the new format. Note the linker when generating the error at .dll or .exe link time tells the name of the offending .obj file lurking within a problem library.
------------------------------------------------------------------------------------
The VS 2017 Preview suppose to solve this, but still It looks like a new debug format is in use since VS 2017.3 I guess.
Regards
Here is the link to the issue posted on the dev community thing: https://developercommunity.visualstudio.com/content/problem/95867/fatal-error-lnk1103-debugging-information-corrupt.html
Quote from: fearless on November 28, 2017, 02:29:48 AM
Here is the link to the issue posted on the dev community thing: https://developercommunity.visualstudio.com/content/problem/95867/fatal-error-lnk1103-debugging-information-corrupt.html
The solution I have posted is from the same page...lol.
I'm not sure I buy there answer.. apparently 15.5 pre-release is working..?
IF they did change the debug info format in obj files, they be duty bound to support both old and new formats alike, a) this wouldn't have been more work as the existing format logic would already be present and b) how could they possibly justify changing a mandatory and essential part of the entire build process without warning possibly breaking millions of sources, tools and libs that simply cannot be re-compiled against this latest version... also why would it work with 15.2 and 15.5 (but not 15.3) a minor version increment like that shouldn't be introducing features like a completely new format for debug information, also given that MS rely mainly on their PDB file format for more complex/extensive debugging data support for .net etc...
Quote from: johnsa on November 28, 2017, 05:45:05 AM
I'm not sure I buy there answer.. apparently 15.5 pre-release is working..?
IF they did change the debug info format in obj files, they be duty bound to support both old and new formats alike, a) this wouldn't have been more work as the existing format logic would already be present and b) how could they possibly justify changing a mandatory and essential part of the entire build process without warning possibly breaking millions of sources, tools and libs that simply cannot be re-compiled against this latest version... also why would it work with 15.2 and 15.5 (but not 15.3) a minor version increment like that shouldn't be introducing features like a completely new format for debug information, also given that MS rely mainly on their PDB file format for more complex/extensive debugging data support for .net etc...
I couldn't agree more!
Today 15.4.5 update is out so I'll upgrade the VS later this day and come back with more info.
Ok, well I updated to 14.4.5.. I still don't ever get :
Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
But I do still get exactly the same issue as before which is :
fatal error LNK1318: Unexpected PDB error; OK (0) ''
This later issue for some reason doesn't occur when I use the version of link i mentioned before from the x86 host folder instead of x64.
Let me know how you get on with the first issue, if perhaps deleting all the intermediate files helps (ilk, pdb etc). Or possibly terminating the symbol services I've seen mentioned in some posts.
Ok, after updating I now get :
fatal error LNK1318: Unexpected PDB error; OK (0) ''
when trying to use HostX64 version
AND
Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
when trying to use HostX86 version
... WTF ...
Apparently the fix is ONLY in VS 2 017 15.5, which is still only in pre-release and has been for months.. they're now on 5 which I'm busy downloading:
https://www.visualstudio.com/en-us/news/releasenotes/vs2017-preview-relnotes
I will let you know if this helps.
I can confirm pre-release of 15.5 fixes
Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
This is using the link found in the HostX86 folder.
The link in HostX64 however still produces this error:
fatal error LNK1318: Unexpected PDB error; OK (0) ''
Quote from: johnsa on December 02, 2017, 03:39:17 AM
I can confirm pre-release of 15.5 fixes
Linker Tools Warning LNK4209
debugging information corrupt; recompile module; linking object as if no debug info
The file contains bad CV information; recompile the module and relink.
This is using the link found in the HostX86 folder.
The link in HostX64 however still produces this error:
fatal error LNK1318: Unexpected PDB error; OK (0) ''
Thanks, johnsa.
I'm not sure using a linker from previous VS versions is a good idea. Pdb error must be generated by debugger because the format generated by "an old linker" is not the correct one.
Looks like 15.5.xx Preview resolve this issue, but for now the VS Preview gets installed side-by-side, which I don't like it at all. I'll wait for the release version (= update of the current version 15.4.xx). I agree it's taking quite a lot of time since the issue was reported for the first time.
Thanks for all you effort.
Regards,
Igor
I'm tempted to report the other PDB error to MS as well, as clearly these are new issues that didn't exist before, they've cocked something up in Link.. and it's only been since the middle of the year.. Not that I think they'll take much notice.. :)
VS 2017 15.5 is now available as regular update (not as as side-by-side Preview instance).
I have just updated VS 15.4 to 15.5.
There is no linker error any more, so this update solved the pdb format issue.
Works like a charm.
:t
I can only find it available still a preview 5, where did you find the update ? :) It's not showing in my VS notifications either.
Quote from: johnsa on December 06, 2017, 03:32:16 AM
I can only find it available still a preview 5, where did you find the update ? :) It's not showing in my VS notifications either.
VS showed me the available update 15.5.
I have no idea why this is not the case for you.
Have you tried the Tools\Extensions and Updates drop down menu option? A dialog opens to select updates.
Igor
BTW: I noticed your are on the UASM developer team. Great work, keep up! :t
Thanks :) Will do,
Yeah I checked there , still nothing.. I'm using VS 2017 Pro, maybe it hasn't been applied to Pro yet ?
That might be the case. I'm using the Community version.
15.5.2 is now available for Visual Studio Professional, so I can remove the preview. Yay :)
I am using the latest Microsoft (R) Incremental Linker Version 14.12.25831.0 and the latest UASM v2.46, Dec 14 2017
With this code:
; Assemble with
; uasm64 -c -win64 -Zp8 /Sg /WX /Zi main.asm
;OR with
; ml64 -c -Zp8 /Sg /WX /Zi main.asm
; link /ENTRY:start /SUBSYSTEM:windows /MACHINE:X64 /FIXED /DEBUG /DEBUGTYPE:CV /PDB:"main.pdb" main.obj
option casemap:none
includelib \masm32\Lib64\kernel32.lib
ExitProcess proto :dword;
.code
start Proc
sub rsp,8
int 3
mov ecx,0
call ExitProcess
start Endp
end
When assembled with MASM and debugged on Windbg I see the source:
(http://www.atelierweb.com/a/windbgmasm.jpg)
When assembled with UASM and debugged on Windbg I don't see the source:
(http://www.atelierweb.com/a/windbguasm.jpg)
No errors, all linked perfectly.
Just tried with VS and WinDbg x64, VS automatically opened the source file, windbg I had to manually open it to start but then it was all working fine, although I've had that same issue always with Windbg tbh..
(http://www.terraspace.co.uk/debug.jpg)
deleted
I haven't tried to be honest, I never use windbg only Visual Studio, it's a much nicer environment to debug in, and profile etc etc..
Hi,
by simple comparison I decided to find out why the 64 bit version of the Microsoft linker does not work, I make an empty project, with hope the whole difference will be visible, PDB processing stops here -Ln 2816
00 00 00 00 00 00
FF FF FF FF 1A 09 2F F1 48 00 00 00 28 02 00 00
F9 00 00 00 01 00 00 00 55 01 00 00 01 00 00 00
71 01 00 00 01 00 00 00 09 01 00 00 01 00 00 00
C5 00 00 00 01 00 00 00 39 01 00 00 01 00 00 00
8D 01 00 00 01 00 00 00 29 01 00 00 01 00 00 00
E1 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00
the logic is
mywindow1.pdb_ml_link_x64 - ml64 & link64 - Ok
mywindow1.pdb_uasm64_bad_x64_linker - uasm64 & link64 - mywindow1.obj : fatal error LNK1318: Unexpected PDB error; OK (0) ''
mywindow1.pdb_uasm64_x32_Link - uasm64 & link32 - Ok
Where
mywindow1.pdb_uasm64_x32_Link
and
mywindow1.pdb_ml_link_x64,
different in content :icon_rolleyes:, after that I compared jwasm64 and ml64, this bug or structure change is already present there, the size of the object files is the same, I decided to debug a bit, the place with a fatal error occurs at the first pass in the procedure
00007FF78240A2EF | 48 8B CE | MOV RCX, RSI |
00007FF78240A2F2 | E8 85 06 01 00 | CALL <link.IMAGE::FPdbEarlyTypeMerge> |
00007FF78240A2F7 | 84 C0 | TEST AL, AL |
00007FF78240A2F9 | 0F 85 67 04 00 00 | JNE link.7FF78240A766 |
00007FF782435994 <link.AppendOp> | 40 53 | PUSH RBX |
00007FF782435996 | 48 83 EC 30 | SUB RSP, 30 |
00007FF78243599A | 44 8B 02 | MOV R8D, DWORD PTR DS:[RDX] |
00007FF78243599D | 48 8B D9 | MOV RBX, RCX |
00007FF7824359A0 | 44 88 4C 24 20 | MOV BYTE PTR SS:[RSP + 20], R9B |
00007FF7824359A5 | E8 36 44 FE FF | CALL <link.CTaskQueue::Append> |
00007FF7824359AA | 83 F8 01 | CMP EAX, 1 |
00007FF7824359AD | 0F 84 9F B4 03 00 | JE link.7FF782470E52 |
00007FF7824359B3 | 48 83 C4 30 | ADD RSP, 30 |
00007FF7824359B7 | 5B | POP RBX |
00007FF7824359B8 | C3 | RET
Append failed :( Maybe someone has an idea, how to approach the problem from the other side :idea:
Hi friends,
problem with fatal error LNK1318 has been fixed, this means that in the next release all versions of the Microsoft linker should link even third-party modules without error in the debugging information, I hope everything is finally fixed and we will be able to test the linker for a 64 bit system with debugging information from UASM.
The bug reporting system is very convenient and simple, you just need to give exact examples, with the source code and binary file. Another problem that is covered in the topic here http://masm32.com/board/index.php?topic=6508.msg69749#msg69749 and http://masm32.com/board/index.php?topic=6447.msg69055#msg69055 added to the processing chain for the Microsoft support service. :eusa_clap: :eusa_clap: :eusa_clap: :eusa_clap: :t
Hi friends,
I am happy to inform everyone that in the latest release 14.15.26726 of Visual Studio already fixed all compatibility errors in the x64 version of the linker (Hostx64/x64/link.exe). I just checked the x64 linker in projects on UASM64, including a link with debugging information, everything works fine :P :t
Dont forget to add to the batch file the line - taskkill /f /im mspdbsrv.exe
Here we talked about this bug ...
http://masm32.com/board/index.php?topic=6571.msg70398#msg70398 (http://masm32.com/board/index.php?topic=6571.msg70398#msg70398)
This may be due to some bad configuration here but I can't debug UASM from within VS 2017 when using the Visual Studio 2017 toolset. It works when using older toolsets. It happens both in x86 and x64.
It works with MASM.
AW, try in VS Properties, Link, Commandline, Additional Option: /debug
It will trigger debug and you can use breakpoints instead int 3
There are a problems with UAsm codeview info.
UAsm generate some useless debug info, like for __m128 __m256 ...
cvdump (https://github.com/Microsoft/microsoft-pdb/tree/master/cvdump)
Thank you, habran. :Thmbsup: