action("generate_v8_context_snapshot") for arm32 target on x86_64

[Jeff Dagenais]

Hi guys!

I'm trying to get action("generate_v8_context_snapshot") to work in my buildroot build.

I have configured the real target build to arm (32bits) but have pretty much let the chromium build system decide the rest of the variables, especially those for v8 context snapshotting.

The result is that chromium's build system properly (in my current understanding) chooses //build/toolchain/linux:clang_x86_v8_arm and expects the debian_sid_i386-sysroot to exist. I used build/linux/sysroot_scripts/install-sysroot.py --arch=i386 when I got the error about it missing.

$ cat build/libcef-jfd/out/Release/args.gn (WITH COMMENTS ;)
clang_base_path = "/path/to/my/buildroot/BASE_DIR/host/usr"
clang_use_chrome_plugins = false
clang_version = "11.0.1"
custom_toolchain = "//build/toolchain/linux/unbundle:default"
target_cpu = "arm"
target_os = "linux"
target_sysroot = "/path/to/my/buildroot/BASE_DIR/host/arm-buildroot-linux-gnueabihf/sysroot"

# I can't use the buildroot pkg-config which are wrappers which add buildroot paths in personality variable.
# I had to change pkg_config.gni to make the v8 scope run not use the sysroot of the target (arm),
# but instead use the sysroot variable, which for the v8 scope, contains the path to debian_sid_i386-sysroot.
# I also had to modify pkg_config.gni to use the host_pkg_config and args instead of the real target
# pkg-config tool (more details below...)
host_pkg_config = "/usr/bin/pkg-config"
fatal_linker_warnings = false
enable_basic_print_dialog = false
disable_ftp_support = true
enable_linux_installer = false
enable_nacl = false
enable_remoting = false
enable_service_discovery = false
enable_vr = false
ozone_platform_wayland = false
rtc_use_pipewire = false
use_clang_coverage = false
use_gnome_keyring = false
use_gtk = false
ffmpeg_branding = "Chrome"
proprietary_codecs = true
arm_tune = "cortex-a9"
arm_float_abi = "hard"
arm_fpu = "vfpv3-d16"
arm_use_neon = false
is_debug = false
is_official_build = true
is_component_build = false
blink_symbol_level = 0
symbol_level = 0
cc_wrapper = "ccache"
use_cups = false
use_libpci = true
use_pulseaudio = false
use_v8_context_snapshot = true
enable_widevine = false
use_vaapi = false

So I don't understand how the v8 snapshot build can work for anyone since I had to to modify build/config/linux/pkg_config.gni to also actually specify the //build/linux/debian_sid_i386-sysroot when it invokes `pkgresult = exec_script(pkg_config_script, args, "value")` in the scope of the v8 toolchain build config. Otherwise the paths returned by pkg-config.py were very absolute paths appended to my buildroot made arm sysroot (or vice-versa, can't remember now). I can produce a patch here for the discussion if needed.

I have successfully built v8_context_snapshot_generator but it fails to run because tools/v8_context_snapshot/BUILD.gn:action("generate_v8_context_snapshot") doesn't do anything special to instruct the dynamic linker to use the files from //build/linux/debian_sid_i386-sysroot.

And even then, after manually invoking v8_context_snapshot_generator with a modified LD_LIBRARY_PATH to prioritize debian_sid_i386-sysroot, I get a failure because some libs in the sysroot rely on libdbus-1.so.0 which is nowhere to be found in that sysroot:

```
.../build/linux/debian_sid_i386-sysroot$ ~/find_libdbus_dependants.sh
./usr/lib/i386-linux-gnu/libavahi-client.so.3 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libpulse.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-13.0.so depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libdbus-glib-1.so.2.3.4 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libgnome-keyring.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libpulse.so.0.21.1 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libgnome-keyring.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libavahi-client.so.3.2.9 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libpulse.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so.0.0.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatspi.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libgnome-keyring.so.0.2.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatspi.so.0.0.1 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libatspi.so.0 depends on libdbus-1.so.0

.../build/linux/debian_sid_i386-sysroot$ find -name "libdbus-1.so.*"
./lib/i386-linux-gnu/libdbus-1.so.3.19.11
./lib/i386-linux-gnu/libdbus-1.so.3
```

So at this point, it is so hard and broken for me that I am starting to question my strategy entirely. Can you provide any help? Am I indeed using this as intended? Should I maybe just stick with my real arm sysroot and invoke v8_context_snapshot_generator from qemu?


Thanks for any help whatsoever!

[Hitoshi Yoshida]

Hi Jeff,

Thank you for the deep investigation!  But the only thing I can advise you is to rethink if you actually need V8 context snapshot or not.

It is used for a performance improvement, and Chromium can be built and run without it.

> the v8 snapshot build can work for anyone

Unfortunately, this is not correct.  It is quite difficult to set up toolchains to make the generator buildable on cross-build environments,

and we gave up support of V8 context snapshot on ChromeOS, when we released it. (crbug.com/764576)

2021年2月26日(金) 22:05 Liviu Rau <livi...@chromium.org>:

I am not familiar with this so I'm including the owners of v8_context_snapshot in the conversation.

--

Hitoshi Yoshida (Peria)

email: pe...@chromium.org

[Dirk Pranke]

switching my reply to this thread as per request ...

It sounds like you roughly know what you're doing and I don't see any obvious mistakes jumping out at me. 

Unfortunately, I'm caught in both a time and machine resource crunch at the moment and don't have much time to really try to dig into this and debug what's going on. And, as peria@ says, getting the snapshot to work is indeed very finicky.

The only other suggestion I might make is to make sure you can do a stock Android 32-bit ARM build given your checkout; that'll ensure that the 32-bit x86 configuration *is* correct and you're getting the things you should be getting. Once you have that compiling, then maybe try switching things to your target toolchain and sysroots and see if you can bisect sets of changes to the GN args where things stop working. That said, it might be that trying to use a 32-bit linux arm target build won't work that well at all, as it's not a configuration we directly support and might be buggier.

If you don't get anywhere, I may have more time next week to be able to help. You might want to take this to a bug so people can follow along a bit more easily.

-- Dirk

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAJnxdXDtVmnT0Tkh%2B9Y%2BMpPXbNcKotewWsVY8dm5du4CqqTLYg%40mail.gmail.com.

[Nico Weber]

A few more pointers (apologies if they're not new):

- There are three toolchains that are interesting: The target toolchain (32-bit arm in your case), the host toolchain (64-bit intel in your case), and the v8 snapshot toolchain (needs to produce binaries that run on host but have same bit width as target, so hopefully 32-bit intel in your case), cf https://source.chromium.org/chromium/chromium/src/+/master:v8/gni/snapshot_toolchain.gni;l=35?q=v8_.*toolchain&ss=chromium

- This constellation is tested very well in android builds, but android builds don't use the big v8 context snapshot that includes blink (https://source.chromium.org/chromium/chromium/src/+/master:tools/v8_context_snapshot/v8_context_snapshot.gni;l=18)

- Linux builds use the big v8 context snapshot, but its cross-build story isn't tested by our bots since we don't officially support linux arm builds

So I wouldn't be surprised if your use case falls between the cracks and you need to hack up GN files a bit -- this combination of settings isn't commonly used, as far as I know.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEoffTB-SEU2SxU%2BFGXOcmxygcszGFESwCsov6te4psRJfHokg%40mail.gmail.com.

[Jeff Dagenais]

On Feb 26, 2021, at 11:57, Hitoshi Yoshida <pe...@chromium.org> wrote:

Thank you for the deep investigation!  But the only thing I can advise you is to rethink if you actually need V8 context snapshot or not.

It is used for a performance improvement, and Chromium can be built and run without it.

Yes, I have abandoned it for now as a lower priority item. Will see later.

Maybe we can produce the snapshot as a "first boot after update" thing on the target, and cache the result on some non-volatile memory. 

> the v8 snapshot build can work for anyone

Unfortunately, this is not correct.  It is quite difficult to set up toolchains to make the generator buildable on cross-build environments,

and we gave up support of V8 context snapshot on ChromeOS, when we released it. (crbug.com/764576)

Not worth it?

What's weird though is that the `gn gen ...` phase complains about the debian_sid_i386-sysroot not present and instructs to use install-sysroot.py --arch=i386 (for a target_cpu=arm anyway) to fix even if use_v8_context_snapshot is false!

We'll have to see about that because this would cause a download of the archive on every build in our farm. Suggestions? Would someone be able to give clues as to where to add some sort of `if (use_v8_context_snapshot)` to skip the configuration of the sysroot for v8_context_snapshot when they are to be ignored at build time anyway?

Cheers!

[Jeff Dagenais]

Hi all,

On Feb 26, 2021, at 15:07, Nico Weber <tha...@chromium.org> wrote:

A few more pointers (apologies if they're not new):

- There are three toolchains that are interesting: The target toolchain (32-bit arm in your case), the host toolchain (64-bit intel in your case), and the v8 snapshot toolchain (needs to produce binaries that run on host but have same bit width as target, so hopefully 32-bit intel in your case), cf https://source.chromium.org/chromium/chromium/src/+/master:v8/gni/snapshot_toolchain.gni;l=35?q=v8_.*toolchain&ss=chromium

Yup, I knew nothing of chromium and gn when I started, and I know now way more than I thought I would need to accomplish this.

- This constellation is tested very well in android builds, but android builds don't use the big v8 context snapshot that includes blink (https://source.chromium.org/chromium/chromium/src/+/master:tools/v8_context_snapshot/v8_context_snapshot.gni;l=18)

- Linux builds use the big v8 context snapshot, but its cross-build story isn't tested by our bots since we don't officially support linux arm builds

So I wouldn't be surprised if your use case falls between the cracks and you need to hack up GN files a bit -- this combination of settings isn't commonly used, as far as I know.

Ok, so that makes sense with what I've seen then.

Right now I've simplified my setup even more to not rely at all on any buildroot artifacts thinking maybe chromiums build system defaults can do a good job. There's nothing in the environment variable that gn should pick up on and I've removed many cross-compile args and just kept "target_os" and "target_cpu". Here is my gn gen call:

buildtools/linux64/gn gen out/release --args="clang_use_chrome_plugins=false target_cpu=\""arm"\" target_os=\"linux\" chrome_pgo_phase=0  host_pkg_config=\"/usr/bin/pkg-config\" fatal_linker_warnings=false disable_ftp_support=true enable_background_mode=false enable_basic_print_dialog=false enable_linux_installer=false enable_nacl=false enable_remoting=false enable_service_discovery=false enable_vr=false link_pulseaudio=false ozone_platform_wayland=false rtc_use_pipewire=false use_clang_coverage=false use_gnome_keyring=false use_gtk=false use_viz_devtools=false  ffmpeg_branding=\"Chrome\" proprietary_codecs=true arm_tune=\"cortex-a9\" arm_float_abi=\"hard\" arm_fpu=\"vfpv3-d16\" arm_use_neon="false"  is_debug=false is_official_build=true is_component_build=false  blink_symbol_level=0 symbol_level=0 cc_wrapper=\"ccache\" use_cups=false use_libpci=true use_pulseaudio=false use_v8_context_snapshot=false enable_widevine=false use_vaapi=false"

I have 3 install-sysroots.py performed:

$ ls -1 build/linux | grep debian

debian_sid_amd64-sysroot

debian_sid_arm-sysroot

debian_sid_i386-sysroot

It fails at configure (gn gen) with pkg_config.gni for nss:

/build/config/linux/pkg-config.py -s /.../chromium/src/build/linux/debian_sid_arm-sysroot -a arm nss -v -lssl3 -d

The pkg-config exits with code 4, debugging shows PKG_CONFIG_LIBDIR is properly set to .../debian_sid_arm-sysroot/usr/lib/pkgconfig:...debian_sid_arm-sysroot/usr/share/pkgconfig

"libnss.*" indeed doesn't exist in any of the debian_sid sysroots. What the??

I know these sysroots are provisioned by repot_tools(right?), but are they actually used by the builds? Am I the only one publicly speaking about doing a linux (non-android) arm 32bit compilation?

Thanks for all your help guys!

[Jeff Dagenais]

Just a update on that nss problem...

On Feb 26, 2021, at 22:59, Jeff Dagenais <jdag...@tesla.com> wrote:

buildtools/linux64/gn gen out/release --args="clang_use_chrome_plugins=false target_cpu=\""arm"\" target_os=\"linux\" chrome_pgo_phase=0  host_pkg_config=\"/usr/bin/pkg-config\" fatal_linker_warnings=false disable_ftp_support=true enable_background_mode=false enable_basic_print_dialog=false enable_linux_installer=false enable_nacl=false enable_remoting=false enable_service_discovery=false enable_vr=false link_pulseaudio=false ozone_platform_wayland=false rtc_use_pipewire=false use_clang_coverage=false use_gnome_keyring=false use_gtk=false use_viz_devtools=false  ffmpeg_branding=\"Chrome\" proprietary_codecs=true arm_tune=\"cortex-a9\" arm_float_abi=\"hard\" arm_fpu=\"vfpv3-d16\" arm_use_neon="false"  is_debug=false is_official_build=true is_component_build=false  blink_symbol_level=0 symbol_level=0 cc_wrapper=\"ccache\" use_cups=false use_libpci=true use_pulseaudio=false use_v8_context_snapshot=false enable_widevine=false use_vaapi=false"

I have 3 install-sysroots.py performed:

$ ls -1 build/linux | grep debian

debian_sid_amd64-sysroot

debian_sid_arm-sysroot

debian_sid_i386-sysroot

It fails at configure (gn gen) with pkg_config.gni for nss:

/build/config/linux/pkg-config.py -s /.../chromium/src/build/linux/debian_sid_arm-sysroot -a arm nss -v -lssl3 -d

The pkg-config exits with code 4, debugging shows PKG_CONFIG_LIBDIR is properly set to .../debian_sid_arm-sysroot/usr/lib/pkgconfig:...debian_sid_arm-sysroot/usr/share/pkgconfig

"libnss.*" indeed doesn't exist in any of the debian_sid sysroots. What the??

I know these sysroots are provisioned by repot_tools(right?), but are they actually used by the builds? Am I the only one publicly speaking about doing a linux (non-android) arm 32bit compilation?

I had a poisoned pkg-config in my PATH (in linuxbrew's bin). Too bad the very explicit poison message I carefully put in there was not displayed by pkg-config.py.

When I removed linuxbrew bin from my PATH, gn gen finished properly, but when compiling I get the error that the clan binaries are not there: third_party/llvm-build/Release+Asserts/bin/clang++

This is because my chromium source comes from a tar.bz2 and have not used depot_tools I imagine. Not sure if this is the path of least resistance anymore.

I still have a build issue but this thread has served it's purpose.

Thanks again for all your insights and help.