Re: [tor-bugs] #26475 [Applications/Tor Browser]: ESR60-based Tor Browser bundles are not built reproducibly with Stylo enabled using rustc > 1.25.0

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#26475: ESR60-based Tor Browser bundles are not built reproducibly with Stylo
enabled using rustc > 1.25.0
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Immediate                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam201810,       |  Actual Points:
  GeorgKoppen201810                              |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:45 alexcrichton]:
 > Oh sorry about this, that's a good discovery! Those settings definitely
 engage a lot of LLVM infrastructure that's not otherwise engaged, which
 could help explain why something nondeterministic is coming out the other
 end.
 >
 > The settings in `bootstrap` are pretty confusing, but what's happening
 here is either rustc is compiled with 16 codegen units (each crate turns
 into 16 object files) which are then optimized as a set with ThinLTO or
 each compiler crate is compiled into one object file and no ThinLTO is
 used.
 >
 > To clarify is the compiler's own binary nondeterministic when the
 compiler's crates are built with 16 CGUs + ThinLTO? Or is the compiler's
 binary deterministic but its output deterministic?

 When the compiler's crates (in fact just the macOS libstd + code it
 depends on) are built with 16 CGUs + ThinLTO its *output* is non-
 deterministic but *only* if I use `-C lto` (if I drop `-C lto` all is
 fine, too). The binary might, too, be non-deterministic, I have not
 checked. We are currently not concerned with getting a reproducibly built
 rust compiler. Right now, just the output that compiler gives us matters.

 > In terms of impact of these settings:
 >
 > * 1 CGU builds are basically equivalent to 16 CGUs + ThinLTO. The 1 CGU
 build is slower to compile the compiler (less opportunities for
 parallelism), but is likely 1%-ish faster than the 16 CGUs + ThinLTO.
 > * The 16 CGUs + ThinLTO is the default setting (as you've found)
 > * If 16 CGUs are used without ThinLTO, the resulting compiler is
 probably horrendously slow (lots of missed inlining opportunities).
 >
 > Or put another way, if you disable ThinLTO you'll want to be sure to
 also compile with one codegen unit, which should happen in rustbuild via
 the above block.

 Okay, thanks for those explanations, really helpful.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26475#comment:46>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs