Tracking down a debugger bug lead me to the surprising discovery that recent Microsoft linkers amass giant piles of stale data in PDBs, even when all incremental build options are disabled.
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
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...
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.
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.
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
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
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.
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.