On 06/04/12 17:19, Xinliang David Li wrote:
Another usage is FDO performance tuning trying build with different options/parameters, so it is common.
This is in our build system for build reproducibility.
If you're trying different options, your builds are not repeatable, so I'm not totally sure why you're using random seed.
The problem is that, when generating a new set of object files from the coverage files of the previous compilation, the old coverage files no longer match the new object files. Without some kind of way of distinguishing this, the coverage machinery gets confused. The random seed is the way of making this distinction, and allows the coverage machinery to know that when dumping data from executing the new object file, that the coverage file contains information about an old object file -- and so can truncate the file. If the random seed matches, it can't do that and then (if you're lucky) notices the function checksums don't match.
I wonder if there's some way of propagating some kind of 'generation' count in the face of using the same random-seed. I'll have a think.
nathan
