Enable zstd compression support in lld in Chromium

[Zijie He]

Nico, Collin and Clang maintainers,

Recently a change in Fuchsia to enable zstd compression cannot be built in Chromium due to the lack of zstd support. E.g.

```

FAILED: test_child_process exe.unstripped/test_child_process "python3" "../../build/toolchain/gcc_link_wrapper.py" --output="./test_child_process" --strip="../.....(too long) ld.lld: error: ../../third_party/fuchsia-sdk/sdk/arch/arm64/sysroot/lib/Scrt1.o:(.debug_abbrev) is compressed with ELFCOMPRESS_ZSTD, but lld is not built with zstd support ld.lld: error: ../../third_party/fuchsia-sdk/sdk/arch/arm64/sysroot/lib/Scrt1.o:(.debug_info) is compressed with ELFCOMPRESS_ZSTD, but lld is not built with zstd support

```

The feature was supported by llvm starting from 16.0.0, and now we are at 17.0.0.

```

~/chromium/chromium/src$ third_party/llvm-build/Release+Asserts/bin/lld-link --version LLD 17.0.0

```

So I'd like to know if it's possible to enable this feature in the llvm we are using.

Thank you.

        .Hzj_jie

[Nico Weber]

That's a fuchsia-side CL. Fuchsia ships its own clang binary. Why do you need to use Chromium's clang to build Fuchsia?

[Zijie He]

The fuchsia change would be rolled into chromium via SDK, and we link the so files into the final binaries in Chromium. The error log was coming from a Chromium build.

        .Hzj_jie

[Nico Weber]

Petr, was it intentional that https://fuchsia-review.googlesource.com/c/fuchsia/+/578403 leaks into the SDK? Maybe it should be behind some arg that's disabled for SDK builds?

--
To unsubscribe from this group and stop receiving emails from it, send an email to clang+un...@chromium.org.

[Zijie He]

Yes, it has been disabled in SDK by a following change. But I do have a concern of the difference between Chromium and Fuchsia which may eventually reduce the blob deduplication and increase the final size of the smart display images.

        .Hzj_jie

[Nico Weber]

Are you shipping debug info on the device?

[Roland McGrath]

That's not relevant. The build ID embedded in a stripped binary is (by essential design) dependent on the whole of the unstripped binary. So if you compile the same thing with different debuginfo formats but otherwise identical code/data segments, you will have a different build ID and not an identical binary to be shipped to devices that can be deduplicated.  I'm not sure if there's any expectation of Chromium building linked binaries that are expected to be identical to ones in the Fuchsia SDK, but that's the concern that Zijie was expressing as I understand it.

[Zijie He]

Thank you Roland for the detailed explanation. I didn't know such details up front. But yes, it seems quite reasonable to me.

In fuchsia, the binaries are stored in blob format and there is a global blob deduplication, so generally speaking, we need to build the binaries as close as other components on the final image to reduce the overall size and meet the very restricted storage capacity of smart displays.

        .Hzj_jie

[Nico Weber]

I'm not sure I understand what you mean. Chrome is built as a single statically linked binary. What should it be deduplicated against?

[Roland McGrath]

Deduplication only applies to final linked binaries, i.e. executables, shared libraries, or loadable modules. You aren't shipping any of those that replicate something that exists elsewhere, except for the whole shared library files (e.g. libc) that you just copy verbatim from the SDK.  So I don't think lost deduplication is in fact a relevant concern for building Chromium's Fuchsia package.

[Zijie He]

This swarming run contains the list of files we generate for the fuchsia image: https://chrome-swarming.appspot.com/task?id=63f09168fb310110.

The files like libEGL.so, libGLESv2.so and lib/libfuchsia_egl.so are either coming from fuchsia SDK or third_party, and I doubt they may be different from the ones in other components if we do not use the same linkage configuration.

But, yes, I agree the discussion is slightly far away from the original question.

        .Hzj_jie

[Roland McGrath]

Any files that come from the Fuchsia SDK and go directly into your package should be just direct copies of the `runtime/...` files from the SDK, not modified in any way by your build.  That's what ensures the expected deduplication will happen.  I suspect this is already so.  (Those files are already fully stripped, so "modifying" them by rerunning llvm-strip on them might actually be done now and actually not modify the bits in the file whatsoever, but it's a good idea to make sure nothing is modifying them at all.)

I think the only relevant issue about the debuginfo is that the Fuchsia SDK includes static archive libraries (and crt1.o) that are statically linked into the ELF binaries you produce using the Chromium toolchain.  The linker in that toolchain needs to be able to handle those as input files.  (Whether or not it then delivers compressed debuginfo in the linked binaries is up to you.)  So we'll need to be sure that the linkers anybody is using at build time to link with archive libraries (and crt1.o) from the Fuchsia SDK are capable of handling new kinds of ELF section contents before we can start including those new kinds of ELF section contents in the static linking artifacts (.a and .o files) published in the SDK.

[Zijie He]

Since a follow change disabled the zstd compression in the fuchsia SDK, the so files in the SDK and chrome packages for fuchsia would be different than the same so files from the fuchsia tree.

And yes, it's the proposal to enable zstd compression *support* in the chromium tool chain. Whether we should use zstd or not is the different issue we were discussing above.

.Hzj_jie

[Roland McGrath]

Ah yes, that's true. In the current workaround state, deduplication between SDK shared libraries and the same shared libraries in the Fuchsia system image is being lost.  That is an important thing to note.  Thanks for pointing that out!  Let's get ASAP to a place where we can use compressed debuginfo in the SDK.

[Nico Weber]

We try to keep the build environment of our clang fairly hermetic, which includes building dependencies from source (on Linux/Mac/win). If you want to contribute code to build zstd, the code is here: https://source.chromium.org/chromium/chromium/src/+/main:tools/clang/scripts/build.py;l=246?q=Build.py%20file:clang We mirror it out here if you don't already have a chromium checkout: https://chromium.googlesource.com/chromium/src/tools/clang/ It'll probably look similar to the zlib and libxml2 functions in there.

[Zijie He]

Thank you all for the input. I can take a look unless Petr would like a committed timeline.

        .Hzj_jie

[Roland McGrath]

Petr is out until next week. I think we'd like it ASAP but there is no hard deadline.

Thanks!

[Zijie He]

I noticed the zstd was explicitly disabled three months ago due to the missing head files in the sysroot. https://crbug.com/1444500. Have there been any updates since then?

        .Hzj_jie

[Roland McGrath]

You don't want any zstd code from your sysroot, you want a local hermetic build of zstd from source specifically to use in your clang build.

[Zijie He]

I think the sysroot is the way Chromium builds the clang, May @Nico Weber have more backgrounds? Also add @pa...@chromium.org and @ha...@chromium.org as the original contributors of the bug https://crbug.com/1444500.

        .Hzj_jie

[Roland McGrath]

The sysroot is what you use for the essential system ABI you want to build for.  As Nico mentioned, other dependencies like zlib and libxml2 are already built from source for hermetic static linking with the toolchain build, so that's the model you want to follow for zstd.

[Nico Weber]

Yup, what Roland said 🙂

[Zijie He]

It seems like I need to follow libxml2, zlib is only used on Windows. I think I got a clear idea about what I need to do. I will get back to you later with the change.

Thank you Roland and Nico.

        .Hzj_jie

[Zijie He]

I now need either @Nico Weber or @Hans Wennborg 's help to

1) Upload zstd-1.5.5.tar.gz to gs://chromium-browser-clang/tools/.

   ```

$ VER=1.5.5
$ curl -O \
   https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-$VER.tar.gz
$ gsutil cp -n -a public-read zstd-$VER.tar.gz \
   gs://chromium-browser-clang/tools

   ```

2) Grant access permission to publish a change to chromium/src/tools/clang for reviewing.

Thank you.

        .Hzj_jie

[Hans Wennborg]

On Wed, Aug 16, 2023 at 3:10 AM Zijie He <zij...@google.com> wrote:

I now need either @Nico Weber or @Hans Wennborg 's help to

1) Upload zstd-1.5.5.tar.gz to gs://chromium-browser-clang/tools/.

   ```

$ VER=1.5.5
$ curl -O \
   https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-$VER.tar.gz
$ gsutil cp -n -a public-read zstd-$VER.tar.gz \
   gs://chromium-browser-clang/tools

   ```

Done.

 

2) Grant access permission to publish a change to chromium/src/tools/clang for reviewing.

chromium/src/tools/clang is a read-only mirror, so it's not possible to upload changes to it. For uploading a patch, you'll need to use the regular chromium repository (the scripts are in the tools/clang/scripts/ directory).

[Zijie He]

Awesome, thank you Hans. I am a one-off contributor, requesting write permission of gs://chromium-browser-clang/tools may not be the right choice.

I will move forward to make the change in the chromium repository instead.

        .Hzj_jie