使用vscode调试emcc构建的大型应用wasm
准备工作
- vscode安装了WebAssembly DWARF Debugging, 可在
Extensions面板直接搜索@id:ms-vscode.wasm-dwarf-debugging - 构建的wasm的参数必须是
-g且不能使用-gseparate-dwarf - 在
.vscode目录, 已经有了launch.json文件
vscode调试的工作原理(我猜的)
调试的主要原理是WebAssembly DWARF Debugging通过vscode驱动Chrome打开, 利用Remote debugger通信的方式, 获取在Chrome上运行的wasm文件, 最终完成符号表的解释.
VS Code会通过浏览器的wasm URL重新请求资源以建立调试连接.
开始调试
一般通过vscode驱动chrome打开的.launch.json配置大概如下:
{
"type": "chrome",
"request": "launch",
"name": "Debug My Wasm",
"url": "http://localhost:8080"
},
如果是小型应用, 这时候就可以在源代码打断点了. 但是对于大型应用, 你编译的wasm项目甚至不是当前调试wasm的项目, 如果你熟悉C/C++ DevTools Support (DWARF), 那么肯定是要配置Path substitutions, 我举个例子:
# 将编译调试信息记录的路径映射成系统本地路径
/home/user/myproject Z:\home\user\myprojectvscode也要有相应的配置才可以, 它就是字段sourceMapPathOverrides, 如:
{
"type": "chrome",
"request": "launch",
"name": "Debug My Wasm",
"url": "http://localhost:8080",
"sourceMapPathOverrides": {
"file:///home/user/myproject/*": "Z:/home/myproject/*"
}
},
注意协议头file://, 以及一些与C/C++ DevTools Support (DWARF)的区别.
OK, 配置完成. 这时候你就可以启动调试了!
网页的wasm加载完, 通常还要等一段事件, 这取决于你的wasm大小, 以及你的网速
与C/C++ DevTools Support (DWARF)的对比
其实vscode调试wasm的工具也是基于C/C++ DevTools Support (DWARF)来构建的, 目前整体用下来感觉没什么优势(还额外装了扩展呢), 主要体现在:
- 断点启动相对于浏览器要慢, 且没有任何提示. 因为上文所说的, 在vscode调试的时候, 会重新下载一次wasm.
- 虽然使用了扩展, 但是浏览器
devtools调试中的限制(如部分变量读取无法显示, 条件断点等), 在vscode上也同样不行.
一些更极端的场景说明
不知道你有没遇过这样的项目:
- 开发环境要配置一大堆host才能跑起来, 而且正式环境host跟开发环境host高度重合, 这时候你直接改系统的host就很难受. 因此使用了浏览器扩展的代理
- 开发环境一定要
https才能跑起来
如果是, 那么恭喜你, 请继续往下看, 因为:
- 你配置的浏览器代理, vscode驱动的Chrome一般用不了
- 你的wasm文件服务器可能是个http的服务, 在https环境用不了(浏览器安全限制)
所幸vscode启动Chrome时, 可以传参数, 以下仅供参考:
{
"type": "chrome",
"request": "launch",
"name": "Debug My Wasm",
"url": "http://localhost:8080",
"sourceMapPathOverrides": {
"file:///home/user/myproject/*": "Z:/home/myproject/*"
},
"runtimeArgs": [
// 建议你创建一个新的目录
"--user-data-dir=C:\\<调试的Chrome用户目录>",
"--profile-directory=<Profile目录名>",
// 允许http的不安全资源
"--ignore-certificate-errors",
"--allow-insecure-localhost"
]
},
这样, 你启动的调试Chrome就会拥有平常开发Chrome的功能, 且基于http请求的wasm也能正常加载了, Happy Coding!
