Communicate randomization seed to the compiler (Build Artifact)

[connorkuehl]

We need a way to tell Clang what our randomization seed is.

[tim-pugh]

11 depends on this.

[connorkuehl]

Acceptance criteria:

• [ ] Generate a build artifact containing the seed so that we can reproduce builds

• [ ] Find a way to communicate this seed to the Clang compiler

• [ ] Incorporate the seed with randstruct. Go to each instance where we shuffle our data structures and make sure it uses a random number generator furnished with our seed.

[jcantrell]

Interesting methods found so far: ParseCodeGenArgs CreateFromArgs ParseArgs Clang.ConstructJobs -- handles command line arguments?

[connorkuehl]

I didn't catch what file we were looking at when you shared your screen yesterday :sweat_smile:

Were you looking at clang/include/clang/Driver/Options.td?

[jcantrell]

Well I feel sheepish, I hadn't noticed that file since I was just poking around in the debugger. Do you have any insight on how these .td definitions are used in the actual code? I'm kind of out of my depth here. IE, how did you go about finding SemaDeclAttr.cpp and figuring out that that's where the attributes defined in the .td file are handled?

[connorkuehl]

Do you have any insight on how these .td definitions are used in the actual code?

Not concretely, I think that clang/lib/Basic/Warnings.cpp is an example of usage, but this is just from a quick glance after grepping.

how did you go about finding SemaDeclAttr.cpp and figuring out that that's where the attributes defined in the .td file are handled

This was a lucky case. It was documented in the Clang CFE Internals Manual.

[jcantrell]

So far I've been looking at how "-fmessage-length" is handled, because it takes its own argument, much like our "-randsturct-seed" will. Still figuring out how the numerical argument is saved. Relevant ag: $ ag fmessage_length clang/include/clang/Driver/CC1Options.td 423:def fmessage_length : Separate<["-"], "fmessage-length">, MetaVarName<"">,

clang/include/clang/Driver/Options.td 1260:def fmessage_length_EQ : Joined<["-"], "fmessage-length=">, Group;

clang/lib/Frontend/CompilerInvocation.cpp 1550: Opts.MessageLength = getLastArgIntValue(Args, OPT_fmessage_length, 0, Diags);

clang/lib/Driver/ToolChains/Clang.cpp 4391: if (Arg *A = Args.getLastArg(options::OPT_fmessage_length_EQ)) {

[jcantrell]

Current status: I have figure out how to add a switch, just not an argument to a switch

[connorkuehl]

Would it be feasible to add your switch into clang/include/clang/Driver/Options.td and then handle it in CompilerInvocation::ParseFrontendArgs()?

In that method, would you be able to retrieve the argument like they do here?

After getting the value of the argument, we'd need some way to store it in our Randstruct class. :thinking: We could probably employ the use of a global, lazy-loaded singleton for our Randstruct class in this case. So once we have the argument, we summon the singleton, give it the seed, and then when Randstruct fires up, Randstruct can ask the Singleton what the seed is. Or some creative re-imagining of this.

Or, better yet, if C++ has some way of having a const that behaves like Java's final to where it can be uninitialized at first but once it is initialized it is initialized once and only once?

Well that turned in to a rambling stream of consciousness. I hope it's at least somewhat helpful.

[jcantrell]

Status up date: i think i know what to do after it's handed off to the child process, my hangup is doing that handoff. In short, finding how/ where do i add it to Command.Arguments?