New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed CLR spec change: allow timestamp header to be deterministic hash with upper bit 1 #4518
Comments
This should be primarily request for PE file format spec change. AFAIK, the PE file format spec is maintained by Microsoft C++ compiler team. The CLI file format is meant to be a strict extension of PE file format. ECMA-335 has the PE file headers as 'informative text only'. This informative text is essentially copy of the relevant part of PE file format spec. cc @CarolEidt |
@gafter afaik the initial approach was to set timestamp to 0 (dotnet/roslyn@04462c4) and this is also how Mono's mcs implemented it, any reason why this didn't work out for you? |
@gregg-miskelly You were the strongest push-back on using a timestamp of 0 for deterministic builds. Do you want to comment here? |
Using a timestamp of 0 has proved problematic in the past. There are many tools which rely on timestamp being a non-zero value. In order to use 0 I think we'd need to have a very compelling use case. |
@jaredpar can you elaborate a bit more on "many tools"? Are those internal Microsoft tools or 3rd party ones? Since this is supposed to be an offset from the epoch I'd be very curious how 0 breaks those tools 😄 |
@akoeplinger right, building on January 1 1970 would seem legal.
|
probably something we can add to https://github.com/dotnet/runtime/blob/main/docs/design/specs/Ecma-335-Augments.md |
We'd like the Roslyn compilers to be deterministic. One obstacle is the timestamp in the assembly header. We propose to use a deterministic hash of compiler inputs (or a hash of the rest of the assembly, excluding the timestamp) to produce bits to use in the timestamp, and we'll set the upper bit to 1. For this to be "legal", we need the spec to allow random-looking bits in the timestamp when the timestamp's upper bit is set to 1.
/cc @jaredpar @tmat
The text was updated successfully, but these errors were encountered: