4 Comments
Jan 15Liked by Casey Muratori

It’s not even the MSVC compiler, it’s the MS linker’s fault! And even worse: The larger the PDB file, the longer it takes the linker to build the executable. So you build gets slower and slower. We’ve experienced this issue when creating obj files with builtin CodeView information from scratch and then feeding them to the MS linker. That’s why I added these lines to Jon’s compiler (about a year ago): https://twitter.com/LubaRaphael/status/1746815998013907008

Expand full comment
author

Are we sure it isn't _also_ the compiler? I avoided suggesting it was specifically the compiler or the linker in the article because I haven't done any tests to determine whether this behavior is isolated to one or the other, and it could be both, no? Especially if you use the /Fd switch in your builds to target a specifically-named PDB for all stages...

- Casey

Expand full comment
Mar 1·edited Sep 2

Sorry for the late reply. I didn't check my Substack notifications.

No, I’m certain that it’s not the compiler because we create the obj files from scratch every time in Jai. The debug info is nested inside those obj files which we then feed to the MS linker. So it’s the linker that amends (and sometimes corrupts) the .PDB file with every build.

I can’t rule out that MSVC has an _additional_ problem. It can emit the debug information as .PDB file for some build types even if it is only creating.OBJ files (not executables), so it could also have a bug when doing that.

But since the problem also exists when using the Jai compiler (i.e. without involving MSVC at all) and I know Jai doesn’t mess with .PDB files at all, it’s definitely the linker’s fault.

Expand full comment
Jan 25·edited Jan 25

I'm not sure if it's normal behavior, but I just laughed and felt joy when, on raddebugger a single built in my cli built the entire program without one single error.

Expand full comment