WebKit调试环境配置

赵裕(vimerzhao)

2025-01-04 (最后修改: 2025-01-05)

本文约 1600 字，阅读需 4 分钟。

Overview

之前构建过一次WebKit，详见小记WebKit的构建，当时刚刚接触WebKit，很多做法不对，这次重新进行了构建，并搭建了一个调试环境，因此再次简单记录一下。

依赖

之前是在自己的远程开发机（CentOS8）上安装各种依赖，经常失败而且还容易冲突。这次学聪明了，用Docker的Ubuntu22镜像进行构建，而且依赖也可以从Webkit的脚本直接安装：

Tools/wpe/install-dependencies

如此，就解决了依赖问题.

如果要交叉编译，我可以安装一个arm架构的docker镜像，如

docker pull arm32v7/debian:12

再在这个docker中执行依赖安装脚本，安装好后把/usr/include 和 /usr/lib 导出。再写一个交叉编译的cmake脚本：

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR armv7l)
set(CMAKE_CROSSCOMPILING ON)
set(CMAKE_SYSROOT $ENV{CUSTOM_CMAKE_SYSROOT})

# very important...
# adjust the default behavior of the FIND_XXX() commands:
# search programs in the host environment
# search headers and libraries in the target environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

SET(ENV{PKG_CONFIG_PATH} "${CMAKE_SYSROOT}/usr/lib/arm-linux-gnueabihf/pkgconfig")
SET(ENV{PKG_CONFIG_LIBDIR} "${CMAKE_SYSROOT}/usr/lib/pkgconfig:${CMAKE_SYSROOT}/usr/share/pkgconfig")
set(ENV{PKG_CONFIG_SYSROOT_DIR} ${CMAKE_SYSROOT})

# ONLY doesn't do anything when CMAKE_FIND_ROOT_PATH is empty. Without this,
# CMake will wrongly search host sysroots for headers/libraries. The actual path
# used here is fairly meaningless since CMake doesn't handle the NDK sysroot
# layout (per-arch and per-verion subdirectories for libraries), so find_library
# is handled separately by CMAKE_SYSTEM_LIBRARY_PATH.
set(CMAKE_FIND_ROOT_PATH ${CMAKE_SYSROOT})


# Clang target triple
set(triple armv7a-linux-gnueabihf)
# for release
# add_compile_options("-mcpu=cortex-a7" "-mfpu=neon-vfpv4" "-mfloat-abi=hard" "-O3" "-DNDEBUG")

就可以回到x86构建arm的产物了。

总之，docker在辅助构建上确实非常好用。

构建命令

cmake -DPORT="WPE" -DCMAKE_BUILD_TYPE=Debug -B build \
  -G Ninja \
  -DDEVELOPER_MODE=ON -DENABLE_EXPERIMENTAL_FEATURES=OFF \
  -DENABLE_WPE_1_1_API=OFF \
  -DUSE_JPEGXL=OFF -DUSE_LIBDRM=ON \
  -DENABLE_WPE_PLATFORM_WAYLAND=OFF \
  -DENABLE_BUBBLEWRAP_SANDBOX=OFF \
  -DENABLE_ASSERTS=OFF

解释下后面几个： WPE_PLATFORM_WAYLAND是因为我后面要基于headless调试，而且我的远程开发机也没wayland环境。bubblewrap同样是因为远程开发机上运行有报错而先关闭。ENABLE_ASSERT也是同样有报错而关闭。这些都相对不重要。

记录一些遇到的问题

部分目标文件没生成

错误信息:

clang++: error: no such file or directory: '/workspace/WPEWebKit/build/WebCore/DerivedSources/JSWebXRInputSource+Gamepad.cpp'
clang++: error: no input files
ninja: build stopped: interrupted by user.

之前没遇到过类似问题，但注意到有以下错误信息:

[2804/7034] Generate bindings (WebCoreBindings)
/usr/bin/ccache: invalid option -- 'E'
/usr/bin/ccache: invalid option -- 'E'
/usr/bin/ccache: invalid option -- 'E'

猜测是ccache的原因，如下：

export CC="ccache clang" && export CXX="ccache clang++"

改成：

export CC="clang" && export CXX="clang++"

就正常了

Docker下调试WebKit

因为是在Docker下编译的，想着直接就在Docker下调试算了，但遇到很多错误，docker毕竟不是虚拟机，应该是限制太多，于是改成docker构建，远程开发机运行调试。通过-v映射本地目录，这样clangd索引和调试符号的路径都能保持一致：

docker run --name ubuntu22_for_research -v /data/research:/data/research -it ubuntu-for-webkit:22.04

接下来是一系列错误解决:

bwrap: Creating new namespace failed: Operation not permitted
ERROR: Failed to connect to RealtimeKit: Could not connect: No such file or directory
/workspace/WPEWebKit/Source/WTF/wtf/linux/RealTimeThreads.cpp(192) : void WTF::RealTimeThreads::realTimeKitMakeThreadRealTime(uint64_t, uint64_t, uint32_t)

** (MiniBrowser:657639): ERROR **: 19:21:57.349: readPIDFromPeer: Unexpected short read from PID socket

和

** (MiniBrowser:121698): ERROR **: 22:04:53.583: Failed to start dbus proxy: Failed to spawn child process ?/usr/bin/bwrap? (No such file or directory)

于是安装

yum install -y bubblewrap.x86_64

又遇到错误：

bwrap: Can't find source path /usr/bin/xdg-dbus-proxy: No such file or directory

** (MiniBrowser:125726): ERROR **: 22:07:46.158: Failed to fully launch dbus-proxy: Child process exited with code 1
[1]    125726 trace trap (core dumped)  bin/MiniBrowser --headless

再安装xdg-dbus-proxy.x86_64，最终还是直接关了这个，因为后面发现开了沙箱，调试不便Attach WebProcess。

继续解决:

ERROR: Failed to get RTTimeUSecMax from RealtimeKit: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

应该是一个服务:

$ busctl list # 查看服务
$ yum search realtime   # 
$ yum install rtkit.x86_64 # 这个比较像
$ systemctl start rtkit-daemon.service 
$ systemctl enable rtkit-daemon.service

发现调试不便，于是加上：

-DENABLE_WPE_PLATFORM_WAYLAND=OFF
# 影响Attach，后面再研究
-DENABLE_BUBBLEWRAP_SANDBOX=OFF
# ASSERT可能也要关了，WebKit内部还有些Crash...

运行过程中又遇到2个问题：

Memory pressure relief: pid = 462251, Total: res = 23199744/23199744/0, res+swap = 210894848/211156992/262144
No provider of glViewport found.  Requires one of:
    Desktop OpenGL 1.0
    OpenGL ES 1.0
    OpenGL ES 2.0

对于OpenGL的问题，应该是依赖没安装对，补一波：

yum install mesa-libGL.x86_64 mesa-libEGL.x86_64 libglvnd-gles.x86_64

生成代码索引

如下：

#usage: rewrite-compile-commands [-h] input_file output_file source_dir build_dir
python3 Tools/Scripts/rewrite-compile-commands /data/research/WPEWebKit/build/compile_commands.json /data/research/WPEWebKit/.vscode/compile_commands.json /data/research/WPEWebKit /data/research/WPEWebKit/build/
 python3 Tools/clangd/update-clangd-config /data/research/WPEWebKit/Tools/clangd/clangd-config.yaml.tpl ./.clangd

最离谱的问题

这个错误给我看的一脸懵，运行时发现这个日志：

Memory pressure relief: pid = 607784, Total: res = 62668800/62668800/0, res+swap = 263852032/263852032/0

看了代码感觉应该是内存不够了，于是用htop看了一下

20250101231028

竟然有50G内存一直在被占用…..

半天没Kill掉，于是重启了下远程开发机：

20250102210845

猜测：我有多台设备通过VSCode连接了远程开发机或者其上运行的Docker，有时调试一半离开了，就会断开，导致vscode-lldb进程常驻后台一直占用内存。

上周我就发现，另外一个项目，改一个文件编译加链接竟然要5分钟，还经常被Kill，而之前1分钟都不到，其实也是这个原因，重启后这个项目的增量构建耗时又回到了1分钟内，离谱。

总阅读量次。