Everett — personal blog · 中文

使用 deno_core 开发 JavaScript 运行时（编译）

Sun, 31 Jul 2022 00:00:00 +0000

编译：Everett。原文作者：Bartek Iwańczuk · 2022-07-29 · Roll your own JavaScript runtime

历史文章：2022 年 7 月的教程，使用 Rust 1.62、deno_core 0.142.0 与 tokio 1.19.2。未按当前版本重新验证。

如果不了解Deno，可以先看看官网 https://deno.land/ 。简单来说，Deno是一个更安全的Node （名字都是反过来的,no_de -> de_no），和Node是一个创始人。

前两天，Deno博客发布了一篇文章《Roll your own JavaScript runtime》

https://deno.com/blog/roll-your-own-javascript-runtime

看到略有“冲动”，今天就给大家翻译一波。注意：翻译不是按字原版翻译，会略做小修改，保持原意不变。所谓“略有冲动”，其实是我半年前也看了一眼Deno文档中的 Embedding Deno https://deno.land/manual/embedding_deno 然而这里啥也木有写，就直接让去看 deno_core 的文档 https://crates.io/crates/deno_core 也木有个入门教程啥的，当时由于我的Rust技术太菜，也就没继续玩耍下去。

好了废话不多说，开始翻译。

正文

这篇文章介绍如何创建一个自定义的JavaScript运行时。叫做runjs。可以把它想象成一个非常简单的Deno。这篇文章的一个目标是开发一个命令行程序，实现执行本地的JavaScript文件，可以读文件、写文件、删文件，以及一个console API。

开始咯。

必备条件

这篇教程假设读者掌握了以下知识：

Rust的基础知识
JavaScript事件循环的基础知识

确保电脑上安装了Rust（和cargo，cargo会自动安装），版本至少1.62.0 。可以访问 https://www.rust-lang.org/learn/get-started 来安装。

$ cargo --version
cargo 1.62.0 (a748cf5a3 2022-06-08)

创建工程

首先，让我们创建一个新的Rust项目，名为runjs：

$ cargo new runjs
     Created binary (application) package

进入runjs文件夹，并用编辑器打开。确保一切正常。

$ cd runjs
$ cargo run
   Compiling runjs v0.1.0 (/Users/ib/dev/runjs)
    Finished dev [unoptimized + debuginfo] target(s) in 1.76s
     Running `target/debug/runjs`
Hello, world!

哦啦！现在开始创建咱们自己的JavaScript运行时啦。

依赖库

下一步，添加依赖 deno_core 和 tokio 。

$ cargo add deno_core
    Updating crates.io index
      Adding deno_core v0.142.0 to dependencies.
$ cargo add tokio --features=full
    Updating crates.io index
      Adding tokio v1.19.2 to dependencies.

现在Cargo.toml文件的内容应该是下面这样：

[package]
name = "runjs"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
deno_core = "0.142.0"
tokio = { version = "1.19.2", features = ["full"] }

deno_core 是Deno团队开发的一个Rust库（crate），它抽象了V8 JavaScript引擎的接口。V8是一个包含很多API的复杂工程，为了更简单的使用V8，deno_core提供了JsRuntime结构，封装了V8引擎的实例（也叫做Isolate），支持了事件循环。

tokio是一个异步Rust运行时，我们用它实现事件循环（event loop）。Tokio可以用来和系统的socket和文件系统交互。deno_core和tokio两者一起可以实现JavaScript的Promise映射到Rust的Future（也就是JS中的async/await映射到Rust的async/await）。

有了JavaScript引擎和一个事件循环之后，我们就能创建一个JavaScript运行时了。

Hello,runjs!

现在开始写一个异步的Rust函数，创建一个JsRuntime实例用于JavaScript的执行。

// main.rs
use std::rc::Rc;
use deno_core::error::AnyError;

async fn run_js(file_path: &str) -> Result<(), AnyError> {
  let main_module = deno_core::resolve_path(file_path)?;
  let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
      module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
      ..Default::default()
  });

  let mod_id = js_runtime.load_main_module(&main_module, None).await?;
  let result = js_runtime.mod_evaluate(mod_id);
  js_runtime.run_event_loop(false).await?;
  result.await?
}

fn main() {
  println!("Hello, world!");
}

这里有很多可以展开说的。异步的run_js函数创建了一个JsRuntime实例，这个实例使用了基于文件系统的模块加载器（deno_core::FsModuleLoader）。接着，我们用js_rutime加载了一个模块（main_module），然后执行（mod_evaluate），以及运行起一个事件循环（run_event_loop）。

这个run_js函数包含了JavaScript代码执行的所有生命周期。但首先，我们需要创建一个单线程的tokio运行时来执行run_js函数：

// main.rs
fn main() {
  let runtime = tokio::runtime::Builder::new_current_thread()
    .enable_all()
    .build()
    .unwrap();
  if let Err(error) = runtime.block_on(run_js("./example.js")) {
    eprintln!("error: {}", error);
  }
}

让我们开始执行一些JavaScript代码。创建一个example.js，我们让它输出Hello runjs!：

// example.js
Deno.core.print("Hello runjs!");

注意：example.js在工程的根文件夹，cargo run 会让根文件夹作为工作目录(working directory)。

注意这里我们用了Deno.core中的print函数，Deno.core是deno_core提供的一个全局有效的内置对象。

现在运行。

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/runjs`
Hello runjs!⏎

成功啦！我们仅用了25行代码就创建了一个可以执行本地文件的简单的JavaScript运行时。当然这个运行时现在还做不了太多事情（例如，不支持console.log）。现在我们已经把V8 JavaScript引擎和tokio集成到了我们的工程中。

添加console API

让我们开始实现console API。首先创建src/runtime.js文件，这个文件可以实现全局的console对象。

// src/runtime.js
((globalThis) => {
  const core = Deno.core;

  function argsToMessage(...args) {
    return args.map((arg) => JSON.stringify(arg)).join(" ");
  }

  globalThis.console = {
    log: (...args) => {
      core.print(`[out]: ${argsToMessage(...args)}\n`, false);
    },
    error: (...args) => {
      core.print(`[err]: ${argsToMessage(...args)}\n`, true);
    },
  };
})(globalThis);

注意，这个runtime.js在src文件夹中。

console.log和console.error函数可以接受多个参数，序列化为JSON（我们可以这样查看非原生的JS对象），并给每条消息加上前缀log或error。这是个“有点古老”的JavaScript文件了，就像在ES modules诞生之前在写浏览器里的JavaScript代码。

这里用了IIFE来执行代码是为了避免污染全局空间。否则，argsToMessage这个辅助函数会在我们运行时里全局有效了。

现在让我们每次运行时都执行这段代码：

let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
  module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
  ..Default::default()
});
+ js_runtime.execute_script("[runjs:runtime.js]",  include_str!("./runtime.js")).unwrap();

注意，这里include_str!是把main.rs同级目录下（也就是src目录下）的runtime.js的内容读取出来。

最后，在example.js中可以调用新增的console API了。

- Deno.core.print("Hello runjs!");
+ console.log("Hello", "runjs!");
+ console.error("Boom!");

执行：

$ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.05s
     Running `target/debug/runjs`
[out]: "Hello" "runjs!"
[err]: "Boom!"

添加文件系统API

首先更新runtime.js文件：

};

+ globalThis.runjs = {
+   readFile: (path) => {
+     return core.opAsync("op_read_file", path);
+   },
+   writeFile: (path, contents) => {
+     return core.opAsync("op_write_file", path, contents);
+   },
+   removeFile: (path) => {
+     return core.opSync("op_remove_file", path);
+   },
+ };

})(globalThis);

我们添加了一个新的全局对象runjs，有三个方法：readFile writeFile和removeFile。前两个是异步的，最后一个是同步的。

你估计要纳闷core.opAsync和core.opSync是什么了，它们是deno_core提供的绑定JavaScript和Rust函数的机制。当JavaScript中调用它们时，deno_core将查找有#[op]属性的同名Rust函数。

让我们更新main.rs来看看实际效果：

+ use deno_core::op;
+ use deno_core::Extension;
use deno_core::error::AnyError;
use std::rc::Rc;

+ #[op]
+ async fn op_read_file(path: String) -> Result<String, AnyError> {
+     let contents = tokio::fs::read_to_string(path).await?;
+     Ok(contents)
+ }
+
+ #[op]
+ async fn op_write_file(path: String, contents: String) -> Result<(), AnyError> {
+     tokio::fs::write(path, contents).await?;
+     Ok(())
+ }
+
+ #[op]
+ fn op_remove_file(path: String) -> Result<(), AnyError> {
+     std::fs::remove_file(path)?;
+     Ok(())
+ }

我们定义了三个JavaScript可以调用的ops，但是要想让JavaScript代码可以调用，我们还需要给JsRuntime注册一个extension。

async fn run_js(file_path: &str) -> Result<(), AnyError> {
    let main_module = deno_core::resolve_path(file_path)?;
+    let runjs_extension = Extension::builder()
+        .ops(vec![
+            op_read_file::decl(),
+            op_write_file::decl(),
+            op_remove_file::decl(),
+        ])
+        .build();
    let mut js_runtime = deno_core::JsRuntime::new(deno_core::RuntimeOptions {
        module_loader: Some(Rc::new(deno_core::FsModuleLoader)),
+        extensions: vec![runjs_extension],
        ..Default::default()
    });

我们可以通过Extensions来配置JsRuntime，暴露Rust函数给JavaScript，还可以做一些更高级的事情（加载额外的JavaScript代码等）。

再次更新example.js：

console.log("Hello", "runjs!");
console.error("Boom!");
+
+ const path = "./log.txt";
+ try {
+   const contents = await runjs.readFile(path);
+   console.log("Read from a file", contents);
+ } catch (err) {
+   console.error("Unable to read file", path, err);
+ }
+
+ await runjs.writeFile(path, "I can write to a file.");
+ const contents = await runjs.readFile(path);
+ console.log("Read from a file", path, "contents:", contents);
+ console.log("Removing file", path);
+ runjs.removeFile(path);
+ console.log("File removed");
+

运行它：

$ cargo run
   Compiling runjs v0.1.0 (/Users/ib/dev/runjs)
    Finished dev [unoptimized + debuginfo] target(s) in 0.97s
     Running `target/debug/runjs`
[out]: "Hello" "runjs!"
[err]: "Boom!"
[err]: "Unable to read file" "./log.txt" {"code":"ENOENT"}
[out]: "Read from a file" "./log.txt" "contents:" "I can write to a file."
[out]: "Removing file" "./log.txt"
[out]: "File removed"

🎉恭喜，我们的runjs运行时现在支持文件系统了。注意我们这里用了很少的代码就实现了JavaScript调用Rust代码：deno_core把JavaScript和Rust之前的通信都搞定了。

总结

在这个简短的例子中，我们实现了一个集成了强大JavaScript引擎（V8）和一个高效事件循环（tokio）的Rust项目。

完整的例子代码，可以参考：denoland’s GitHub

https://github.com/denoland/roll-your-own-javascript-runtime

LLDB 断点 UIPasteboard 的所有方法

Thu, 25 Jun 2020 00:00:00 +0000

iOS14 新增了一个保护隐私的功能，当前App读取其他App复制到剪贴板中的内容时，会有个短暂的提示。如下图：

可以通过断点 UIPasteboard 的所有方法来检查App中与剪贴板有关的所有行为。

断点一个UIPasteboard的所有方法可以用如下命令：

breakpoint set -r '\[UIPasteboard .*\]$'

先断点到main，然后lldb终端输入以上命令。

（上图只截图了一部分UIPasteboard的方法）

总结

嗯，大家小试一下～会发现除了我们自己调用，系统也偶尔会触发UIPasteboard相关调用。

很有趣～

如何快速列出 App 的所有 +load 方法

Tue, 28 Apr 2020 00:00:00 +0000

Objective C +load 方法是个神奇又邪恶的方法。

当新手得到它时，会惊讶于它的神奇。
当高手得到它时，会沉迷其中无法自拔。
当老手得到它时，会惊恐于它的邪恶。

多数大型App都已经或者正在想办法去摆脱它。那么，如果快速看到你的App中有多少+load方法，看看中毒有多深。

假设如下场景：

一天你在愉快的用Xcode调试程序，

打开Xcode，按下F5，

突然，你想看一下App中的+load方法有多少？

点击一下Pause，然后输入

br s -r "\+\[.+ load\]$"

然后输入

br list

或许你会惊讶，原来我的App中+load这么多（或者少）

原理

使用了lldb的breakpoint命令。

br s -r "正则"
就是 
breakpoint set -r "正则"

通过正则匹配符号设置断点。

小问题

那么想想，如果这些+load方法中的代码出现了crash，你的crash监控（bugly等等）能监控到吗？

当然得到的90%的回答是：不会Crash的。

让我想起了特朗普的一句话：我的”代码”很完美。

哈哈 :)

总结

很有趣:)

哎，我好菜，我要去学习《基于桥的全量方法Hook》了

http://satanwoo.github.io/2020/04/26/TrampolineHookOpenSource/

LLDB：如何在函数 return 处下断点

Thu, 23 Apr 2020 00:00:00 +0000

有一个代码行很多的复杂函数，内部有很多return，单步调试很慢，如何快速找到哪一行return了？

例如代码：

void foo() {
    int i = arc4random() %100;
    
    if (i > 30) {
        if (i < 40) {
            return;
        }
        if (i > 77) {
            return;
        }
        if (i < 66) {
            return;
        }
    }
    
    switch (i) {
        case 0:
            return;
        case 1:
            return;
        case 2:
            return;
        case 3:
            return;
        case 4:
            return;
        default:
            return;
    }
}

int main(int argc, const char * argv[]) {
    foo();
    return 0;
}

假设foo是个很长很复杂有很多return的函数，如何知道是通过哪一行return的呢？

可以使用lldb的断点

breakpoint set -p return
或者
br set -p return

首先在foo第一行加断点

断点触发后，控制台输入 br set -p return

然后continue，就会断点到函数return的那一行了。

很有趣~

C++ 类中持有的 Objective-C 对象何时 dealloc

Fri, 17 Apr 2020 00:00:00 +0000

在使用Objective C++时，可以用C++的struct或者class存储Objective C对象。

例如：

struct CppStruct {
    MyObject *obj;
};

那么突然想，如果CppStruct析构了，MyObject会dealloc吗？不用多想，肯定也会。但如何做到的呢？

写段代码验证下，

@interface MyObject : NSObject
@end
@implementation MyObject
- (instancetype)init {
    self = [super init];
    if (self) {
        NSLog(@"MyObject init");
    }
    return self;
}
- (void)dealloc {
    NSLog(@"MyObject dealloc");
}
@end

struct CppStruct {
    MyObject *obj;
    CppStruct() {
        NSLog(@"CppStruct constructor");
    }
    ~CppStruct() {
        NSLog(@"CppStruct destructor");
    }
};

CppStruct * CreateStruct() {
    CppStruct * s = new CppStruct();
    s->obj = [[MyObject alloc] init];
    return s;
}

void FreeStruct(CppStruct *s) {
    delete s;
}

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        CppStruct *s = CreateStruct();
        FreeStruct(s);
    }
    return 0;
}

如下输出

可知，MyObject确实dealloc了。

那么，断点到dealloc，看看怎么调用到的。

看到上图有两个 ~CppStruct()，其中一个调用了 objc_storeStrong，objc_storeStrong 进一步触发了MyObject的dealloc。

从上图可知，一定是编译器生成了objc_storeStrong调用的代码。

看下Disassembly，确实生成了objc_storeStrong调用代码。

进一步实锤。

LLVM 怎么去生成的这个逻辑，就不去翻了哈。

参考

上面调试中用了可编译的objc runtime，GitHub上有很多，可以如下搜索对应objc版本即可：

https://github.com/search?q=objc+779.1 https://github.com/LGCooci/objc4_debug

总结

以后可以大胆的用C++ struct 存储Objective C对象了。

很有趣 :)

探索 WhatsApp 应用名称中的隐藏字符（LRM）

Mon, 30 Mar 2020 00:00:00 +0000

欢迎大家观看这期的“走近科学之WhatsApp神秘符号”～

案发现场

大概半年甚至更久之前，在使用frida-ios-dump时，偶然发现WhatsApp这个应用的名称有点奇怪。

frida-ios-dump 是一款越狱iOS上的App砸壳工具（也可以列出iOS的应用列表）。地址：https://github.com/AloneMonkey/frida-ios-dump

仔细看下图的WhatsApp：

WhatsApp的名称左侧对齐与其他App不同。

… 多少次匆匆擦肩而过 … 多少次视如不存在 …

直到今天我终于好奇了一次，想看看这里为什么没有对齐。

开始

砸，砸一下试试。

python dump.py net.whatsapp.WhatsApp

砸完，如下图。出现个问号。?WhatsApp.ipa，问号是什么。

准备mv到其他文件夹研究下，就在此刻…

神秘字符\342\200\216出现了，正好奇着…

一搜

随手一搜 … 还真搜到了 :)

https://graphemica.com/200E

打开一看，还真有含义咧～ left-to-right mark

真相大白

Wikipedia也有解释

The left-to-right mark (LRM) is a control character (an invisible formatting character) used in computerized typesetting (including word processing in a program like Microsoft Word) of text that contains a mixture of left-to-right text (such as English or Russian) and right-to-left text (such as Arabic, Persian or Hebrew). It is used to set the way adjacent characters are grouped with respect to text direction.

https://en.wikipedia.org/wiki/Left-to-right_mark

贴个翻译：

左至右符号（Left-to-right mark,LRM）是一种控制字符，或者说是不可见的排版符号。用于计算机的双向文稿排版中。

我再大白话说一句。Left-to-right mark 是个不可见的符号，用来在 从右向左的排版语言（例如阿拉伯语）中包含从左向右的文字。

下图的例子就比较清晰了：在使用了LRM符号后，阿拉伯语（从右向左）中包含了显示的C++（从左向右）。

扩展阅读

有 Left-to-right mark，也有 Right-to-left mark。

https://en.wikipedia.org/wiki/Right-to-left_mark

进一步

把WhatsApp的Info.plist文件拿出来看一眼，似乎没什么特别。

用二进制编辑器看一下。

\342\200\216 就是 0xE2 0x80 0x8E (e2808e)

这样在代码中获取 CFBundleDisplayName 并与其他本地化的语言拼接后，就能保证WhatsApp的顺序从左至右了。

很有趣 :)

在 iPhone 上运行 Android 系统的体验

Fri, 06 Mar 2020 00:00:00 +0000

历史文章：2020 年 3 月在 iPhone 7 上体验的 Project Sandcastle。未按当前版本重新验证。

历史上第一次让Android系统运行到iPhone手机上。目前（2020年3月6日）的版本只支持iPhone7/7 Plus。（iOS系统版本无要求）

Project Sandcastle: Android for the iPhone 项目地址：https://projectsandcastle.org/

正好手头有个iPhone7，体验了下。步骤简单总结下，分享给大家。理想的步骤如下，但由于macOS的安全机制，导致步骤2和3不那么轻松愉快。

使用checkra1n越狱
运行start_mac.sh
运行setup_mac.sh

越狱

下载 https://checkra.in/ 按照步骤越狱。（iPhone使用USB连接Mac。）

越狱后，进入iOS。

下载 Android Build

在 https://projectsandcastle.org/status 下载 Android Build。

解压下载的文件。

setup_mac.sh

iPhone使用USB连接Mac。理想情况下，macOS上执行 ./setup_mac.sh即可。但我执行不太顺利。自带的iproxy和两个动态库的签名首次执行还需要信任。但其实功能就是iproxy的功能，因此下面手动把 setup_mac.sh 中的步骤执行。

可以先ssh连接下iOS，确保手动连接成功。然后参考如下步骤。

(1)

iproxy 2222 44

(2) 把isetup复制到iOS的/tmp/setup.sh

scp -P2222 -o StrictHostKeyChecking=no isetup root@localhost:/tmp/setup.sh

(3) 两个方法：

一是，FQ。或者，修改setup.sh中的网络连接测试的地址，比如专门测试网能不能上的baidu（看来老外也是对应的用google测试啊）

建议使用FQ的方法，因为这个脚本会下载470MB的文件，我家的Wi-Fi不FQ的话，下载这个文件很慢，FQ后貌似几分钟就好了。

(4) 执行 /tmp/setup.sh

进入DFU 模式

iPhone关机。
同时按音量下 + 关机键，10秒钟（尽量严格的10秒）。
松开关机键，继续保持音量下。
此时手机屏幕会保持黑屏，表示进入了DFU模式。

然后在DFU模式下，执行./start_mac.sh。

理想情况下，执行完成就可以了。但现实很残酷，我见到了下面这个弹窗（内心一万匹羊驼飞奔而过，生怕把手机搞坏了……），当然要点Cancel。

进入 System Preferences -> Security & Privacy -> General，点 Allow Anyway。

此时还不行，为了预防万一，先命令后执行一次

./load-linux.mac

然后就可以点Open了。

但此时重新执行start_mac.sh似乎不能”恢复继续”了，内心X#@%$$。“聪明”的我看了下start_mac.sh的代码，看来可以执行执行这一步。

./load-linux.mac Android.lzma dtbpack

终于成功，iPhone上启动了Android系统。

截图

总结

运行比较卡。
重启就恢复iOS。

还是挺有趣的，视频可抖音搜索 everettjf 查看。

将 iOS 标准输出重定向到 UITextView

Tue, 03 Mar 2020 00:00:00 +0000

历史文章：2020 年的 iOS 标准输出实验，涉及 C 库的内部实现细节。未按当前版本重新验证。

看到一处代码挺有意思，iOS项目中把printf打印的内容重定向到了UITextView中。

代码抽出来后，挺简单。

#include <stdlib.h>
#include <stdio.h>

static print_cbk_t gPrintFunc;

static int stdout_redirect(void* prefix, const char* buffer, int size)
{
    if (gPrintFunc)
        gPrintFunc(buffer, size);
    return size;
}

void set_redirect_output(print_cbk_t f)
{
    gPrintFunc = f;

    setvbuf(stdout, 0, _IOLBF, 0); // stdout: line-buffered
    setvbuf(stderr, 0, _IONBF, 0); // stderr: unbuffered

    stdout->_write = stdout_redirect;
    stderr->_write = stdout_redirect;
}

然后在ViewController中类似如下使用：

static UITextView *sTextView = nil;

static void current_output(const char* buff, int len) {
    NSString *text = [sTextView text];
    text = [text stringByAppendingFormat:@"%s",buff];
    [sTextView setText:text];
}

@interface ViewController ()
@property (weak, nonatomic) IBOutlet UITextView *textView;

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view.
    
    sTextView = self.textView;
    
    set_redirect_output(current_output);
        
    printf("hello\n");
    printf("hello\n");
    printf("hello\n");
    printf("hello\n");

}
@end

运行后，printf就到了UITextView中。

原理似乎也没啥可讲的，本身c库就提供支持。

    setvbuf(stdout, 0, _IOLBF, 0); // stdout: line-buffered
    setvbuf(stderr, 0, _IONBF, 0); // stderr: unbuffered

然后这两个函数把标准输出设置为“按行缓冲”和“不缓冲”。也就是进入stdout和stderr的内容都按行或直接输出。这样UITextView就接收到的比较及时了。

水文写起来就是轻松愉快啊~ 有趣就好~

使用 asm 重命名符号

Wed, 19 Feb 2020 00:00:00 +0000

objc 源码中有如下代码 __asm__("_objc_retain")，这个__asm__是啥来？

发现

源码中如下

objc 源码下载 https://opensource.apple.com/tarballs/objc4/

搜索一番，发现是可以rename symbol，写个测试代码：

#include <stdio.h>
void foo(void) __asm__("_objc_release");
void foo(void)  {
    printf("hello world");
}
int main(int argc, const char * argv[]) {
    foo();
    return 0;
}

调试看下

从上图可知，callstack中的symbol不是 foo，而是 _objc_release。

变量

从下面的链接又可知，还可以rename变量的symbol。

int counter __asm__("counter_v1") = 0;

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/Cacgegch.html

总结

似乎可以拿来给dylib做个简单的export symbol混淆？

参考

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.kui0097a/armcc_bcfggcdh.htm
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491f/Cacgegch.html
https://stackoverflow.com/questions/1034852/adding-leading-underscores-to-assembly-symbols-with-gcc-on-win32

函数中的 C++ 静态变量初始化是线程安全的吗？

Mon, 17 Feb 2020 00:00:00 +0000

先说结论，是线程安全，而且有double-checked locking，性能还不错。

探索

通常写C++ Singleton模式时，会很流畅的写下如下代码：

class Hello {
public:
    static Hello & instance() {
        static Hello obj;
        return obj;
    }
    
    Hello() {
        printf("constructor");
    }
    ~Hello() {
        printf("destructor");
    }
    
public:
    int x = 0;
};

那么当使用 Hello::instance() 时，是线程安全吗？ Hello 的构造函数能确保执行一次吗？

把代码扔到 Hopper 看一下

看来是有锁。那就是线程安全咯 :)

进一步

看到这几个方法

__cxa_guard_acquire
__cxa_atexit
__cxa_guard_release

__cxa_atexit 可以是为了在进程结束时调用析构函数。

一番搜索可以找到这个源码 cxa_guard.cxx

https://opensource.apple.com/source/libcppabi/libcppabi-14/src/cxa_guard.cxx

通过obj_guard 实现了一个double-checked locking

inUse会通过obj_guard指向内存的第一个地址存取0和1，实现第一次check。

Hopper中找到这个obj_guard

这个guard variable 是个全局变量。

总结

以后可以愉快的使用这个写法了

    static Hello & instance() {
        static Hello obj;
        return obj;
    }