Archive

Archive for August, 2015

LLVM基金会拿到了非盈利组织的资格

August 21st, 2015 No comments

http://blog.llvm.org/2015/08/llvm-foundation-granted-501c3-nonprofit.html

501(c)(3), 简单说就是免税了.

afl-fuzz vs. mozjs: 1st round.

August 13th, 2015 No comments

第一轮, 随机从 mozilla-central 的回归测试集中选择了几个js文件, 没有使用字典, 默认 afl-fuzz 配置.

结果: 一个 crash 都没有发现.

分析: 这个是合理的. 没有字典直接 Fuzz, 绝大部分都过不了前端的 Parser. (绝大部分的意思是我没有做统计, 直观猜测的)

afl-fuzz-vs-mozjs

V8 也要开始加解释器了, 嘿嘿

August 11th, 2015 2 comments

Issue 4280: Ignition interpreter tracking bug

Ignition: V8 Interpreter

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)

 

SpiderMonkey 回归测试的代码覆盖度

August 8th, 2015 No comments

最简单的方法还是用 GCC/GCOV/LCOV 系列. 以下是方法:

获取之后就可以直接用浏览器打开看了.

mozjs-coverage-regression-tests-20150807

需要注意的是这个只能看到函数覆盖率和代码行覆盖. 更细致的覆盖度, 例如路径覆盖, 可能需要别的工具了(not sure).

从代码覆盖度上看, 还是有一些代码是没有测试到的. 看了一下原因可以分成几类:

  1. 我编译 SpiderMonkey 的时候使用了’–enable-debug’编译, 有一些调试代码没有执行到;
  2. 测试使用的是Mozilla自带的回归测试脚本, 用于交互式执行的部分, 例如 editline, 都没有执行到;
  3. 硬件配置相关的部分, 由于我使用的机器是 X86_64 SSE4.2, 所以有一些特定的代码也是覆盖不到的;
  4. 最后, 就是测试集可以覆盖但是没有覆盖到的代码部分.

完整的覆盖信息可以看 http://hellocompiler.com/spidermonkey/lcov/index.html

使用机器学习算法训练 Language Fuzzer 的一个问题

August 7th, 2015 No comments

使用机器学习的技术来训练针对编译器的 Programming Language Fuzzer, 有一个问题, 就是找到了 bug(s) 之后, 整个 Fuzzer 可能就跑偏了, 重复性的触发已经发现的 bugs.

理想的情况是, Fuzzer 能够发现 Compiler 的某个模块, 针对 PL 中的某个语言的 feature, 已有的测试不充分导致发现了 bug, 于是就更多的生成针对这个模块的 testcase, 但是在这个目标下, 还是尽可能的做到 diversity.