Skip to content
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

[20.09] chromium: Backport various patches from nixos-unstable #108231

Merged
merged 11 commits into from Jan 3, 2021

Conversation

primeos
Copy link
Member

@primeos primeos commented Jan 2, 2021

Motivation for this change

Backport additional patches from nixos-unstable to keep the differences to a minimum and get various improvements.
This'll better work...

I can run the VM test but it would be ideal if someone could test chromium (warning: takes very long to build) manually on NixOS 20.09 as the switch to the system libraries (etc.) could introduce regressions.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Determined the impact on package closure size (by running nix path-info -S before and after)
  • Ensured that relevant documentation is up to date
  • Fits CONTRIBUTING.md.

TredwellGit and others added 11 commits January 2, 2021 16:19
By default GN produces a build with all of the debug assertions enabled (is_debug=true) and including full debug info (symbol_level=2). Setting symbol_level=1 will produce enough information for stack traces, but not line-by-line debugging. Setting symbol_level=0 will include no debug symbols at all. Either will speed up the build compared to full symbols.

(cherry picked from commit a7cbf67)
LLD: https://lld.llvm.org/
When you link a large program on a multicore machine, you can expect that LLD runs more than twice as fast as the GNU gold linker. Your mileage may vary, though.
Link-time optimization (LTO) is supported by default.
Some default settings have been tuned for the 21st century. For example, the stack is marked as non-executable by default to tighten security.

LTO & ThinLTO: https://clang.llvm.org/docs/ThinLTO.html
LTO (Link Time Optimization) achieves better runtime performance through whole-program analysis and cross-module optimization. However, monolithic LTO implements this by merging all input into a single module, which is not scalable in time or memory, and also prevents fast incremental compiles. ThinLTO is a new approach that is designed to scale like a non-LTO build, while retaining most of the performance achievement of full LTO.

PGO: https://llvm.org/docs/HowToBuildWithPGO.html https://blog.chromium.org/2020/08/chrome-just-got-faster-with-profile.html
Allows your compiler to better optimize code for how it actually runs. Users report that applying this to Clang and LLVM can decrease overall compile time by 20%.
Because PGO uses real usage scenarios that match the workflows of Chrome users around the world, the most common tasks get prioritized and made faster. Delivers up to 10% faster page loads.

CFI: https://clang.llvm.org/docs/ControlFlowIntegrity.html https://www.chromium.org/developers/testing/control-flow-integrity
Aborts the program upon detecting certain forms of undefined behavior that can potentially allow attackers to subvert the program’s control flow. These schemes have been optimized for performance, allowing developers to enable them in release builds.
By default, a program compiled with CFI will crash with SIGILL if it detects a CFI violation.

Additionally:
Use minizip instead of zlib. Chromium says zlib but actually uses minizip.
Remove old unused workarounds.
Make shell scripts POSIX compliant.
Update documentation URLs.
Prepare for using system libraries.

(cherry picked from commit 2bb0110)
The build succeeds again as dirmd is no longer required for building.

(cherry picked from commit 97677fa)
We've only set ozone_platform_gbm=false to fix the build with Mesa's
libgbm (vs. Google's own minigbm). However, since this issue has
resolved itself we can now drop it. Building with the recommended
settings should also avoid some issues (e.g. NixOS#104885).

[0]: https://chromium.googlesource.com/chromium/src.git/+/master/docs/ozone_overview.md#drm_gbm

(cherry picked from commit 2d5bb88)
But since Ozone is still experimental I'll keep useOzone in common.nix
for some time.

(cherry picked from commit 063b369)
This enables automatic updates and fixes NixOS#85629.

(cherry picked from commit 6aea53c)
I've removed that option in 063b369 but forgot that M87 still
defaults to use_vaapi=false.

(cherry picked from commit fb0239c)
Copy link
Contributor

@thiagokokada thiagokokada left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code wise LGTM, I am trying to build it now (but I can't guarantee that I will have the patience to build everything).

@thiagokokada
Copy link
Contributor

thiagokokada commented Jan 2, 2021

Result of nixpkgs-review pr 108231 1

1 package failed to build:
  • chromium
4 packages built:
  • chromedriver
  • google-chrome-dev
  • selendroid
  • selenium-server-standalone

chromium seems to have failed to build thanks to a lack of space, but I have sufficient space in my disk 🤔. I am having the same issue building other big packages, so it may be something that I need to configure in nixpkgs-review or some other issue:

  tar: chromium-87.0.4280.66/storage: Cannot mkdir: No space left on device
  tar: chromium-87.0.4280.66/storage/common/database/database_connections.h: Cannot open: No such file or directory
  tar: chromium-87.0.4280.66/storage: Cannot mkdir: No space left on device
  tar: chromium-87.0.4280.66/storage/common/database/database_connections_unittest.cc: Cannot open: No such file or directory
  tar: chromium-87.0.4280.66/storage: Cannot mkdir: No space left on device
  tar: chromium-87.0.4280.66/storage/common/database/OWNERS: Cannot open: No such file or directory
  tar: chromium-87.0.4280.66/storage: Cannot mkdir: No space left on device
  tar: chromium-87.0.4280.66/storage/common/database/database_identifier.cc: Cannot open: No such file or directory
  tar: Exiting with failure status due to previous errors

@primeos
Copy link
Member Author

primeos commented Jan 3, 2021

The VM test was fine so I'll go ahead and hope for the best :)

chromium seems to have failed to build thanks to a lack of space, but I have sufficient space in my disk thinking.

Could be due to /tmp being too small or running out of inodes.

@primeos primeos merged commit 743311f into NixOS:release-20.09 Jan 3, 2021
@thiagokokada
Copy link
Contributor

Could be due to /tmp being too small or running out of inodes.

Makes sense, I use tmpOnTmpfs = true;.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants