Using mold for Chromium discussion. #336
Comments
|
Please explain what you tried from the instructions in the README. |
|
@matu3ba Okay, I have compiled it with stripping, -03, lto, and -march=haswell and -mtune=haswell for max performance :) For example, my main BUILD.gn normally has some loop optimizations I added like "-Wl,-mllvm,-aggressive-ext-opt" and "-Wl,-mllvm,-enable-loop-distribute", |
|
Are you trying LTO? LTO is probably too new to try. We don't and unlikely to support mllvm options as they are LLVM-specific options. |
|
i tried to compile chromium with mold. I use this patch to remove the mllvm options. https://github.com/stha09/chromium-patches/blob/master/chromium-100-compiler.patch After that the compile stops with the error: |
|
@monarc99 You need to remove the thinlto cache lines in //chromium/src/build/config/compiler/BUILD.gn cache_policy = "cache_size=10%:cache_size_bytes=40g:cache_size_files=100000" "/lldltocache:" + [ "-Wl,--thinlto-cache-dir=" + ldflags += [ "-Wl,--thinlto-cache-policy=$cache_policy" ] |
rui314
added a commit
that referenced
this issue
Apr 18, 2022
They are defined as aliases for
--plugin-opt=thinlto-{single-module,cache-dir,cache-policy}.
#336
|
Now mold should be able to handle |
|
Reported the issue to GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105305 |
|
Meanwhile, the Apparently as a consequence, they are now blocking Thus, all |
|
@DAC324 Thanks, let me take a look. What is your gn args? |
|
I am building in an Arch-like manner with a Where the |
|
With |
|
And the next round goes on :( |
|
Update: These unresolved symbol errors seem to have been fixed with |
|
Cool, thank you for trying the latest version. |
|
As I said, the Chromium developers do not like Now that version 1.4.0 does not have that unresolved symbols problem anymore, a new blocker was introduced: |
|
I'd think you shouldn't speculate their feelings. That they do not support mold doesn't necessarily mean they dislike it. It's just unsupported. If you can share me the details of the error, I might be able to fix the issue for you. |
|
Here's the full report: Cross checking now if reverting to ld.lld avoids this crash. |
|
Update: Looks like it is not related to |
|
Next round: |
|
I'm using gentoo and following the guide to just add |
|
|
|
ok, with this patch it almost works on 119.0.6045.199 --- ./build/config/compiler/compiler.gni.orig
+++ ./build/config/compiler/compiler.gni
@@ -37,6 +37,9 @@
# The default linker everywhere else.
use_lld = is_clang && current_os != "zos"
+ # enable together with use_lld
+ use_mold = false
+
# If true, optimize for size.
# Default to favoring speed over size for platforms not listed below.
optimize_for_size = !is_high_end_android && (is_android || is_castos)
--- ./build/config/compiler/pgo/BUILD.gn.orig
+++ ./build/config/compiler/pgo/BUILD.gn
@@ -143,13 +143,8 @@
if (is_win) {
ldflags = [ "-mllvm:-enable-ext-tsp-block-placement=1" ]
} else {
- ldflags = [ "-Wl,-mllvm,-enable-ext-tsp-block-placement=1" ]
}
} else {
- cflags += [
- "-mllvm",
- "-enable-ext-tsp-block-placement=1",
- ]
}
}
}
--- ./build/config/compiler/BUILD.gn.orig
+++ ./build/config/compiler/BUILD.gn
@@ -384,7 +384,9 @@
}
}
- if (use_lld) {
+ if (use_mold) {
+ ldflags += [ "-fuse-ld=mold" ]
+ } else if (use_lld) {
ldflags += [ "-fuse-ld=lld" ]
if (lld_path != "") {
ldflags += [ "-B$lld_path" ]
@@ -601,7 +603,6 @@
if (is_win) {
ldflags += [ "-mllvm:-instcombine-lower-dbg-declare=0" ]
} else {
- ldflags += [ "-Wl,-mllvm,-instcombine-lower-dbg-declare=0" ]
}
}
@@ -717,7 +714,6 @@
# binary size than the default setting of 100.
# TODO(gbiv): We ideally shouldn't need to specify this; ThinLTO
# should be able to better manage binary size increases on its own.
- import_instr_limit = 30
if (is_win) {
ldflags += [
@@ -726,7 +722,6 @@
"/lldltocache:" +
rebase_path("$root_out_dir/thinlto-cache", root_build_dir),
"/lldltocachepolicy:$cache_policy",
- "-mllvm:-disable-auto-upgrade-debug-info",
]
} else {
ldflags += [ "-flto=thin" ]
@@ -766,14 +761,11 @@
import_instr_limit = 5
}
- ldflags += [ "-Wl,-mllvm,-import-instr-limit=$import_instr_limit" ]
-
if (!is_chromeos) {
# TODO(https://crbug.com/972449): turn on for ChromeOS when that
# toolchain has this flag.
# We only use one version of LLVM within a build so there's no need to
# upgrade debug info, which can be expensive since it runs the verifier.
- ldflags += [ "-Wl,-mllvm,-disable-auto-upgrade-debug-info" ]
}
}
@@ -893,7 +885,6 @@
is_android && host_os == "linux",
"MLGO is currently only supported for targeting Android on a linux host")
if (use_thin_lto) {
- ldflags += [ "-Wl,-mllvm,-enable-ml-inliner=release" ]
}
}
@@ -1438,7 +1429,6 @@
# This can be removed once https://bugs.llvm.org/show_bug.cgi?id=40348
# has been resolved, and -mno-outline is obeyed by the linker during
# ThinLTO.
- ldflags += [ "-Wl,-mllvm,-enable-machine-outliner=never" ]
}
asmflags = cflagswith the last issue being: |
|
Sounds like you need |
|
I've adjust limits very big values, but I still get 'Too many open files' error :( Seems that it's another reason... |
|
Another potential knob to tune is |
|
I have the same problem I think this could be a bug. |
|
Are you using fuse or some special filesystem? |
Alex313031
changed the title
|
I'm using ext4. |
|
No fuse or some other overlay filesystem on top of ext4? The issue here is that we close a file descriptor immediately after we open a file and mmap it to memory. mmap'ed file is not usually counted towards the number of opened files. Therefore, "too many open files" error should not usually occur for mold. However, if there's something in your system that intercepts file operations and keep file descriptors open as long as their corresponding files are kept mmap'ed, that's not the case. Some overlay filesystem does that and can cause "too many open files" error. |
|
I am running on native hardware PC (Laptop) under Gentoo, should no fuse or some other overlay filesystem. Edit: Finally find the reason: not enough for mold. |
|
Building chromium with mold causes a |
|
@apprehensions I couldn't reproduce the issue. What is your mold version? I tested it with mold 2.31.0. |
|
I am using the same mold version. I am also using musl, which could be the issue. |
|
Ah, maybe. What is your distro and version? |
|
KISS Linux Community |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello, Im working on a chromium fork called Thorium > https://github.com/Alex313031/Thorium and would like to test using mold instead of lld during linking of the .so files and executables. How would I do this? I know this was one of the inspirations of the creator when making mold. Do I need to install or build/install mold first, or is it included in a chromium checkout? Can I just modify the main BUILD.gn to use LDFLAGS+= [ "-fuse-ld=mold", ]?
The text was updated successfully, but these errors were encountered: