LLVM基金会拿到了非盈利组织的资格
http://blog.llvm.org/2015/08/llvm-foundation-granted-501c3-nonprofit.html
501(c)(3), 简单说就是免税了.
http://blog.llvm.org/2015/08/llvm-foundation-granted-501c3-nonprofit.html
501(c)(3), 简单说就是免税了.
第一轮, 随机从 mozilla-central 的回归测试集中选择了几个js文件, 没有使用字典, 默认 afl-fuzz 配置.
结果: 一个 crash 都没有发现.
分析: 这个是合理的. 没有字典直接 Fuzz, 绝大部分都过不了前端的 Parser. (绝大部分的意思是我没有做统计, 直观猜测的)
Issue 4280: Ignition interpreter tracking bug
Background
The machine code generated by V8’s full-codegen compiler is verbose, and as such, can contribute significantly to the amount of memory used by V8’s heap for typical web-pages (a previous analysis showed that the code-space contributed to around 15-20% of the JS heap). The aim of the ignition project is to build an interpreter for V8 which executes a low-level bytecode, thus enabling run-once or non-hot code to be stored more compactly in bytecode form. An added advantage of the bytecode is that it could be fed into a Turbofan graph generator directly, thereby avoiding the need to reparse the JavaScript source code when optimizing a function
V8 也要开始加解释器了, 架构上跟 SpiderMonkey 基本上没啥差别了. 嘿嘿.
Spartan/Microsoft Edge 的 Chakra 也加入了 Simple JIT, 于是现在四大JS引擎的架构都统一了:
解释器 -> Baseline JIT / Simple JIT -> Opt JIT / Full JIT (Optional Off Threading)
最简单的方法还是用 GCC/GCOV/LCOV 系列. 以下是方法:
1 2 3 4 5 6 7 8 9 10 11 12 |
# 编译 SpiderMonkey CFLAGS="-fprofile-arcs --coverage" CXXFLAGS="-fprofile-arcs --coverage" ~/gecko-dev/js/src/configure --enable-debug && make -j 8 # 跑回归测试集 cd ~/gecko-dev/js/src/tests/ ./jstests.py ~/gcov-mozjs/obj/dist/bin/js cd ../jit-test/ ./jit_test.py ~/gcov-mozjs/obj/dist/bin/js # 生成HTML lcov --capture --directory mozjs-obj/ --output-file mozjs-coverage.info genhtml mozjs-coverage.info --output-directory lcov-output/ |
获取之后就可以直接用浏览器打开看了.
需要注意的是这个只能看到函数覆盖率和代码行覆盖. 更细致的覆盖度, 例如路径覆盖, 可能需要别的工具了(not sure).
从代码覆盖度上看, 还是有一些代码是没有测试到的. 看了一下原因可以分成几类:
完整的覆盖信息可以看 http://hellocompiler.com/spidermonkey/lcov/index.html
使用机器学习的技术来训练针对编译器的 Programming Language Fuzzer, 有一个问题, 就是找到了 bug(s) 之后, 整个 Fuzzer 可能就跑偏了, 重复性的触发已经发现的 bugs.
理想的情况是, Fuzzer 能够发现 Compiler 的某个模块, 针对 PL 中的某个语言的 feature, 已有的测试不充分导致发现了 bug, 于是就更多的生成针对这个模块的 testcase, 但是在这个目标下, 还是尽可能的做到 diversity.
Recent Comments