[Flatpak SDK] Add mold linker

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Adrian Perez]

I have it working locally and intend to do some benchmarks to see how
much faster we can get debug (developer) builds by switching to ld.lld
or ld.mold

For those who may not yet know about it, you can learn about Mold here:

  https://github.com/rui314/mold

While it is still missing a few features, the only important issue is
that Mold does *not* support LTO at the moment:

  https://github.com/rui314/mold/issues/181

Other than this, Mold is perfectly usable today for complex projects
like WebKit, and given that developers typically do not do LTO builds
when working on the codebase, it may already be interesting to have it
in the SDK for those.

[Adrian Perez]

Created attachment 451367 [details]
Patch

[Adrian Perez]

To use Mold, either of these work, tested both with the WPE and GTK ports:

GCC ≥ 12:
  % LDFLAGS=-fuse-ld=mold Tools/Scripts/build-webkit [...]

GCC < 12:
  % LDFLAGS=-B/usr/lib/mold Tools/Scripts/build-webkit [...]

Clang:
  % LDFLAGS=-fuse-ld=mold CC=clang CXX=clang++ Tools/Scripts/build-webkit [...]

Adding “-flto” to {C,CXX,LD}FLAGS will result in linker failures due to
the missing support for LTO in Mold.

[Philippe Normand]

Comment on attachment 451367 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=451367&action=review

> Tools/buildstream/elements/sdk/mold.bst:12
> +- kind: tar
> +  url: https://github.com/rui314/mold/archive/refs/tags/v1.0.3.tar.gz

We usually track git tags instead of release tarballs, at least for projects hosted github. Any special reason to do it differently here?

[Adrian Perez]

(In reply to Philippe Normand from comment #3)
> Comment on attachment 451367 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=451367&action=review
> 
> > Tools/buildstream/elements/sdk/mold.bst:12
> > +- kind: tar
> > +  url: https://github.com/rui314/mold/archive/refs/tags/v1.0.3.tar.gz
> 
> We usually track git tags instead of release tarballs, at least for projects
> hosted github. Any special reason to do it differently here?

Fetching Git repositories when there are tarballs available is wasteful
as it uses more bandwidth and local disk space. It may seem moot, but it
all adds up.

[Adrian Perez]

I had a chat with Philippe and it turns out that referencing Git commits
is what is usually done in the Freedesktop SDK sources — I still wonder
why it's done like that, but for consistency I will change the patch to
use a Git ref.

[Adrian Perez]

(In reply to Adrian Perez from comment #2)
 
> GCC < 12:
>   % LDFLAGS=-B/usr/lib/mold Tools/Scripts/build-webkit [...]

This is actually:

  % LDFLAGS=-B/usr/libexec/mold Tools/Scripts/build-webkit [...]

(In Arch Linux there is no “libexec/” but the Flatpak SDK has it,
that's where my confusion came from.)

[Adrian Perez]

I did seven runs with each linker, took out the outliers,
and got the following results:

 Linker |       Times         |  Avg. | Speedup
 -------+---------------------+-------+------------------
    BFD | 393 403 273 267 274 | 322.0 | 1.00x  (baseline)
   Mold | 117 106  99 107 105 | 106.8 | 3.01x
   Gold |  81 116  82  79  82 |  88.0 | 3.66x
    LLD | 106  70  76  70  72 |  78.8 | 4.09x

For each linker, I first removed the build directory, then ran
the build command to have all the object files built, and for
each run removed “bin/*” and “lib/*.so*” before to make sure
that the time differences measured are caused by switching the
linker. Commands used for each were:

  LDFLAGS=-B/usr/libexec/mold NUMBER_OF_PROCESSORS=33 \
    ./Tools/Scripts/build-webkit --gtk --debug --cmakeargs='-DUSE_LD_LLD=OFF'
  LDFLAGS=-fuse-ld=bfd NUMBER_OF_PROCESSORS=33 \
    ./Tools/Scripts/build-webkit --gtk --debug --cmakeargs='-DUSE_LD_LLD=OFF'
  LDFLAGS=-fuse-ld=gold NUMBER_OF_PROCESSORS=33 \
    ./Tools/Scripts/build-webkit --gtk --debug --cmakeargs='-DUSE_LD_LLD=OFF'
  LDFLAGS=-fuse-ld=lld NUMBER_OF_PROCESSORS=33 \
    ./Tools/Scripts/build-webkit --gtk --debug --cmakeargs='-DUSE_LD_LLD=ON'

This was done using the Flatpak SDK, which means the compiler was
GCC 11.2.0 -- hence the need to use the -B<path> flag to make it use
Mold. I don't know if this might be the cause of the Mold not being
faster but I would not expect that the compiler driver needing to do
program lookups in a different way would cause a slowdown; but it could
as well be an issue in Mold itself.

It would be interesting to use Clang as the compiler (and hence as
driver for the linking) so all linkers can be chosen in the same way
using the -fuse-ld=<name> flag.

Given these numbers, switching from the BFD linker to LLD by default
for debug/development builds should be a no brainer. We have bug #235979
for that =)

[Adrian Perez]

Created attachment 451521 [details]
Patch v2

[Adrian Perez]

(In reply to Adrian Perez from comment #0)

> While it is still missing a few features, the only important issue is
> that Mold does *not* support LTO at the moment:
> 
>   https://github.com/rui314/mold/issues/181

Initial LTO support just landed earlier today:

  https://github.com/rui314/mold/commit/46995bcfc3e3113133620bf16445c5f13cd76a18

\o/

[Philippe Normand]

Thanks! I can include this in the next SDK roll-out which I'm preparing already.

[Adrian Perez]

(In reply to Philippe Normand from comment #10)
> Thanks! I can include this in the next SDK roll-out which I'm preparing
> already.

Sounds good! 👍️

[EWS]

Committed r289801 (247266@main): <https://commits.webkit.org/247266@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 451521 [details].

[Radar WebKit Bug Importer]

<rdar://problem/88958643>