Windows, C++: investigate '/experimental:deterministic' compiler flag

Feature requests: what underlying problem are you trying to solve with this feature?

Investigate MSVC’s /experimental:deterministic flag’s effect, maybe use it in MSVC crosstool. (Maybe put it behind a Bazel experimental flag.)

Motivation: to make C++ builds deterministic. For example, MSVC doesn’t support overriding non-deterministic macros like __DATE__, maybe this flag solves that problem.

What operating system are you running Bazel on?

Windows 10

What’s the output of bazel info release?

release 0.29.1

[shuffle2]

Some other maybe interesting links:

• https://developercommunity.visualstudio.com/content/problem/573023/absolute-paths-for-associated-pdb-files-are-record.html
• https://developercommunity.visualstudio.com/content/problem/589675/implicitly-inline-methods-that-required-non-paged.html

I’ve been playing around with some trial and error and found that:

• d1nodatetime: undefs __DATE__, __TIME__, __TIMESTAMP__. user may redefine them.
• Brepro (should be supplied to all of cl, lib, and link): implies d1nodatetime and sets initial value of those #defines equal to 1. Additionally modifies some data stored in object files to make them binary-identical between builds.
• experimental:deterministic implies Brepro and issues a warning if problematic code is found (usage of __TIME__, etc.)

Using Brepro, INCREMENTAL:NO, and Z7, I’m able to get outputs to be binary-identical between builds on the same computer, with some exceptions: If a .manifest and/or resource file (.rc) is processed during compilation/linking, it creates a temporary file during processing, and for whatever reason, this temporary path is included in the resulting pdb (obviously the temporary has been deleted by the time the build is done, so…pointless). This can be “solved” by just omitting the .rc or using a side-by-side .manifest instead of embedding it. However, pdbs with these different temporary paths inside are completely interchangeable - the difference does not prevent a debugger loading it for example.

d1trimfile:<path[=ENV_VAR]> (seen in above links) sounds like it was originally intended to trim the __FILE__ definition, which it does seem to do in my testing (handy if you use FC, I guess). As discussed in above links, they seem to have made it apply to paths stored in .obj files referencing a pdb as well, which occurs on non-Z7 builds, i.e. Zi builds. Unfortunately my quick test still shows full pdb path being in the eventual exe file.

However…why is this a problem? The differences in the pdb can be seen to be inconsequential and the exe will be identical apart from the pdb path, which is accounted for by existing tools (like debuggers and symsrv, which dont use a path to index the pdb).

Maybe make a request to msvc team to have d1trimfile also apply to the pdb path stored in exe? Since they recently made a related change perhaps it just needs to be asked for.

[dgrunwald]

I got /pdbaltpath:%_PDB% working in a toolchain file:

flag_set(
    actions = all_link_actions,
    flag_groups = [
        flag_group(
            flags = [
                "/Brepro",
                # Tell the linker to embed only the .pdb filename instead of
                # the full path.
                # Note that % has a special meaning for bazel so we need to
                # double it to pass a literal % to the linker.
                "/PDBALTPATH:%%_PDB%%"
            ],
        ),
    ],
),

I still have some trouble fitting /d1trimfile into the toolchain file.