Enable debug and suppress optimization if allowed for bitcode generation

[kquick]

When generating bitcode, the -g flag is always supplied to add debug information to the output bitcode file. The -O0 flag will be specified as well to suppress optimization, unless the new --flags-unchanged/-f argument is specified, in which case the optimization setting (if any) of the original compilation command will be passed to the bitcode generation as well.

[travitch]

I've been thinking about how to make build-bom more general while supporting things like this. I worry that this could be a bit restrictive for related use cases where one might want debug information, but want to see what clang did to their code at -O1 or -O2.

What do you think about a general mechanism like --drop-argument=REGEX and --add-argument=STRING? I can build that out today if that would work.

[travitch]

To expand on my thoughts on what those flags can do:

• You might want to drop -O[123s]
• You might want to drop -s (strip)
• You can add -g and -gdwarf4 (for example)

[kquick]

The approach I took was with the intent that the default usage provided the most useful information in the bitcode output (although "useful" is clearly subjective, so here I'll define it as "closest to the original source"). If the user wanted their bitcode to have more fidelity with the compiled result, the --flags-unchanged argument could be added. I agree this is a bit simplistic, but part of my justification was to make the default, out-of-the-box configuration highly useful and needing to tweak things once you get to more advanced usage cases.

Your approach has more discrete control, but is also more complex. I'm a little worried that the price of this additional control is (a) not having good defaults for the simple starter case, and (b) might allow the user to specify problematic (or conflicting) flags like -E or -S or something already blacklisted. [As a small implementation note, this approach would probably need to pass some sort of structure or array through instead of the simple boolean currently threaded... which might actually end up being a good code optimization since it felt awkward to make so many function signature changes just to make a single config option available down where it was needed.]

Specifics:

• I don't see the need to make -g conditional for the bitcode, although perhaps this is naive, and it does look like there's a lot of variable arguments that can be supplied with -g. Maybe the user just specifies the argument (if any). Alternatively, build-bom automatically supplies -g if no override is specified.
• I do think it should be possible for build-bom to assert the -g itself (and probably drop optimization as well) because this allows it to be used without requiring modifications to whatever build configuration the project is using (and it allows the emitted bitcode to diverge from the executable: the executable can still be optimized and not include debug information).
• If --flags-unchanged is specified, it won't drop optimization, otherwise it drops all optimization (I missed -Os though) and explicitly passes -O0 (all of this is for the bitcode only).
• I also missed -s/strip, but does this actually exist for clang/llvm? Seems like it should be added to the general blacklist.
• I'm also thinking it might be nice to default to adding NIX_CC_USE_RESPONSE_FILE=-1 to the environment in general to prevent the use of response files under nix; there may be other environment variables that might be useful to supply and corresponding controls for those... something else to consider that might be in this same solution space.

All the above is just more background on the approach I took and a bit of pro/con analysis of the two approaches. I think either approach is reasonable, whichever you think is the most useful.

[travitch]

I agree that build-bom should definitely be able to add -g. Part of my concern around changing optimization levels by default is that -O0 is not universally good for analysis either, though I suppose one can always apply opt to that bitcode to turn it into anything else.