[cfe-dev] Feature proposal: Compile Configuration Disclosure

[James Widman]

On Mar 3, 2010, at 5:44 PM, James Widman wrote:

> 2) Where would the configuration disclosure
>   information be output?
> ===========================================
> Personally, I don't care, and I'd be happy to try to follow any request for which there is no obvious contraindication.  But earlier, Doug suggested (in a semi-private email) that each config-disclosure file should be placed beside its associated output file, and that the name simply be something like ${MAIN_OUTPUT_FILE}.config-disclosure.  E.g. for this invocation:
> 
>   clang --disclose-config -c x.cpp -o foo.o
> 
> ...the disclosure file would be placed in 
>    foo.o.config-disclosure
> in the same directory as foo.o (which in this case happens to be the working directory).  (By the way, if anyone is not happy about that filename extension, I'm totally happy to change it.)

I see something about this that might be viewed as a hiccup: --disclose-config needs to be passed on to 'clang -cc1', whose output is a file placed in $TMPDIR.

So from the perspective of 'clang -cc1', the natural name for the disclosure file would be something like:

   $TMPDIR/cc-F6CVkg.s.disclose-config

And programs are expected to clean up whatever they write to $TMPDIR, but disclosure files are meant to persist.  (They're also meant to be visible to the user, and it probably helps the user interface if the filename is based on the output filename one expects when invoking the driver.)

So I can see a few ways to deal with this:

1) Just say that --disclose-config is just an experimental feature, and in this 0.1 version, we want to see what the output looks like before we start worrying too much about command-line interface details like this.  It would work well enough for Clang developers, but it feels a little more half-baked than I would really like.

2) Have the driver deduce an appropriate filename for the disclosure file (as originally suggested above), and pass that name on to 'clang -cc1'.  So even though '-cc1' is outputting an assembly file, the disclosure filename would be "foo.o.config-disclosure".  It would work, but it feels wrong because '-cc1' never actually sees the machine code; it only sees the assembly code.  So to mention 'foo.o' in the disclosure file feels too much like a fib.  (And if we get around to outputting SHA values, it really won't work because '-cc1' will not be privy to the sequence of bytes of the object file.)

3) Let -cc1 make a "*.s.disclose-config" file (based on the name of the assembly file it produces); and make sure the driver removes it before it exits (unless -save-temps is given of course).  But before removing the ".s.disclose-config" file, the driver should read it in, modify the "output file" portion (so that it now references the object file produced by the invocation of the assembler) and then write out a ".o.disclose-config" (where the name is based on the name of the actual object file).

Option (3) seems as close to "right" as we can get for the time being without modifying the assembler.  If/when we can modify the assembler (or if/when '-cc1' just generates object code), we can then get rid of the part where the driver reads in the disclosure file.

Also: I don't know what to do for the -pipe case.  Granted, -pipe doesn't seem to make a difference for now, but presumably it will in the future.  If nothing else, I guess the hash of a stage's output can be used as the base of a disclosure file's name.

James Widman  
-- 
Gimpel Software 
http://gimpel.com