Talk:Mold
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~
:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 16:12, 30 December 2024 (UTC) :: Your reply ~~~~
Gold
As far as I'm aware, the Gold linker's development has stagnated. Fedora is debating kicking it out of the binutils package, it has worse success for linking object files and is no longer relevant for LTO since BFD now supports plugins. Clang is better off with LLD or can fall back to BFD, even with LTO. Do we need to point people to a dying linker? --Unhappy-Ending (talk) 08:33, 10 March 2022 (UTC)
- I agree that there is no point thinking about ever using Gold, but I don't think that the link is particularly harmful. --Matthews (talk) 08:45, 10 March 2022 (UTC)
Speed
We should also try not to hype up the speed too much, as mold is still in early development and as optimizations (maybe) get added will slow link time down. For example, mold ignores -Wl,-O1 which would add link time during the link phase. LLD for example, uses the -Wl,-O2 flag to use zlib compression to create smaller code which adds time during the link phase. --lto-O3 was just added to mold as well, which adds additional link time using more aggressive LTO passes if it's similar to LLD in behavior. --Unhappy-Ending (talk) 08:40, 10 March 2022 (UTC)
- I don't think there's much reason to use mold with LTO. Actually linking ends up being a small part of the time spent when LTO is enabled[1].
- If GCC users are looking for a speedy linker that hasn't been abandoned with LTO support, mold would be have to be it. GCC can use LLD, but only for non-LTO linking. LLD will provide a nice speedup and also offers --icf=all/safe/none options. With mold, GCC users would get --icf and LTO, so that would be something worth looking into.--Unhappy-Ending (talk) 09:01, 10 March 2022 (UTC)
Address randomization
mold recently gained the --shuffle-sections option to randomly shuffle input sections before writing them to an output file. With this option, we can create a stronger form of address randomization. That is, even if you built the same executable in the same way for two Gentoo machines, they'll have the executables that behave the same but with different memory layouts. Are you guys interested in supporting this? --Ruiu (talk) 06:39, 10 May 2022 (UTC)