The official self-hosting repository makes it look simple — just clone, tweak a few configs, run docker compose up -d, and you’re done. But the actual deployment process had quite a few gotchas, and many others in the Issues have run into similar problems. Here’s what I learned, hoping it saves you some trouble.

Gotcha #1: No Emails by Default — Activation Link Hidden in Logs

Aptabase doesn’t configure SMTP out of the box. After registering an account, you won’t receive any email. However, it prints the activation link to the container logs, so you need to check them manually:

1

docker logs -f aptabase_app

Look for a link like this in the output, then open it in your browser to activate your account:

1

https://your-domain/api/_auth/continue?token=eyJhbGciOiJIUzI1NiIs...

This is just a temporary workaround — we’ll configure SMTP later for proper email delivery.

Gotcha #2: HTTPS Is Required — Otherwise Activation Loops Forever

After clicking the activation link, the page kept redirecting back to the login page in an endless loop. After debugging, I found that Aptabase requires BASE_URL to use HTTPS — otherwise cookies and redirects in the auth flow break.

My setup runs on a Mac Mini at home with no public IP, and I didn’t want to deal with certificates manually. The solution: Cloudflare Tunnel with a custom domain.

Setting Up Cloudflare Tunnel

1. Log in to the Cloudflare Dashboard, go to Zero Trust → Networks → Tunnels
2. Click Create a tunnel, choose the Cloudflared type, and give it a name (e.g., mac-mini)
3. Follow the instructions to install and run cloudflared on your Mac Mini. On macOS, use Homebrew:

1

brew install cloudflared

Then connect the tunnel using the command shown on the page (which includes a token):

1

cloudflared service install <your-token>

4. On the tunnel’s Public Hostname page, add a record:
   • Subdomain: stats (or whatever you prefer)
   • Domain: select a domain hosted on Cloudflare, e.g., pastepaw.com
   • Service: http://localhost:3200 (this port matches the Nginx mapping in docker-compose)

Once configured, Cloudflare handles HTTPS certificates automatically. External traffic to https://stats.pastepaw.com is securely forwarded through the tunnel to your Mac Mini.

Gotcha #3: Can’t Get Real User IPs

After deployment, I noticed the dashboard showed the same IP for every user — Cloudflare’s IP, not the actual user’s.

This is a classic Cloudflare Tunnel issue. After traffic passes through Cloudflare’s proxy, the source IP becomes Cloudflare’s server IP. The real user IP is placed in the CF-Connecting-IP HTTP header, but Aptabase (built on ASP.NET Core) doesn’t read this header by default.

The fix is to add an Nginx reverse proxy in front of Aptabase that converts CF-Connecting-IP into the standard X-Forwarded-For header, then point Cloudflare Tunnel at Nginx instead of directly at Aptabase.

Here’s the nginx.conf:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;

        location / {
            proxy_pass http://aptabase:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $http_cf_connecting_ip;
            proxy_set_header X-Forwarded-For $http_cf_connecting_ip;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

With this in place, Aptabase can correctly identify users’ real IPs.

Gotcha #4: Configuring SMTP for Email Delivery

Digging through container logs for activation links isn’t sustainable. Aptabase supports SMTP configuration via environment variables. I chose Resend as the email service — it’s free to sign up and offers 3,000 emails per month, more than enough for a personal project.

Setting Up a Domain in Resend

1. Sign up for a Resend account
2. Go to the Domains page and click Add Domain
3. Enter the domain you want to send emails from (e.g., mail.pastepaw.com — it doesn’t need to match the Aptabase domain)
4. Resend will provide several DNS records to add, typically:
   • An MX record
   • An SPF (TXT) record
   • Several DKIM (TXT) records
5. Add these records in your DNS management panel (e.g., Cloudflare)
6. Go back to Resend, click Verify, and wait for verification to complete (usually within a few minutes)

Generating an API Key

1. In Resend’s left menu, go to the API Keys page
2. Click Create API Key
3. Name it (e.g., aptabase), set permission to Sending access, and optionally restrict it to the domain you just configured
4. Copy the generated key (starts with re_) — this is your SMTP password

Configuring Environment Variables

Add these environment variables to the Aptabase service in your docker-compose.yml:

1
2
3
4
5

SMTP_HOST: smtp.resend.com
SMTP_PORT: 587
SMTP_USERNAME: resend
SMTP_PASSWORD: re_your_API_key
SMTP_FROM_ADDRESS: noreply@mail.pastepaw.com

Note: Use port 587 (STARTTLS), not 465 (Implicit TLS). In my testing, port 465 failed to send emails in a Docker environment, while 587 worked immediately. This is another easy pitfall.

Complete Docker Compose Configuration

Here’s the final, working docker-compose.yml:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

services:
  nginx:
    container_name: aptabase_nginx
    image: nginx:alpine
    restart: always
    depends_on:
      - aptabase
    ports:
      - 3200:80
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    mem_limit: 256m
    cpus: 0.5
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase_db:
    container_name: aptabase_db
    image: postgres:15-alpine
    restart: always
    mem_limit: 2g
    cpus: 2
    volumes:
      - ./db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: aptabase
      POSTGRES_PASSWORD: ${PASSWORD}
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase_events_db:
    container_name: aptabase_events_db
    image: clickhouse/clickhouse-server:23.8.4.69-alpine
    restart: always
    mem_limit: 4g
    cpus: 2
    volumes:
      - ./events-db-data:/var/lib/clickhouse
    environment:
      CLICKHOUSE_USER: aptabase
      CLICKHOUSE_PASSWORD: ${PASSWORD}
    ulimits:
      nofile:
        soft: 262144
        hard: 262144
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase:
    container_name: aptabase_app
    image: ghcr.io/aptabase/aptabase:main
    restart: always
    depends_on:
      - aptabase_events_db
      - aptabase_db
    mem_limit: 2g
    cpus: 2
    environment:
      BASE_URL: https://stats.pastepaw.com
      AUTH_SECRET: replace_with_your_random_secret
      DATABASE_URL: Server=aptabase_db;Port=5432;User Id=aptabase;Password=${PASSWORD};Database=aptabase
      CLICKHOUSE_URL: Host=aptabase_events_db;Port=8123;Username=aptabase;Password=${PASSWORD}
      SMTP_HOST: smtp.resend.com
      SMTP_PORT: 587
      SMTP_USERNAME: resend
      SMTP_PASSWORD: replace_with_your_Resend_API_key
      SMTP_FROM_ADDRESS: noreply@mail.pastepaw.com
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

Create a .env file for the database password:

1

echo "PASSWORD=your_strong_database_password" > .env

Reminder: Make sure to replace AUTH_SECRET with your own random string — you can generate one at RandomKeygen. Don’t use the example value from the official docs.

Starting the Services

1

docker compose up -d

Once all containers are up, visit https://stats.pastepaw.com, register an account, and this time you should receive the activation email properly.

Architecture Overview

Here’s the overall architecture with all components deployed:

Component responsibilities:

• Cloudflare: Manages HTTPS certificates and CDN acceleration, securely forwards external traffic to the Mac Mini at home via Tunnel
• Nginx: Reverse proxy whose core job is converting Cloudflare’s CF-Connecting-IP header into X-Forwarded-For so Aptabase can identify real user IPs
• Aptabase: The core application service — processes events reported by SDKs, manages user accounts, and provides the dashboard
• PostgreSQL: Stores user accounts, app configurations, API keys, and other relational data
• ClickHouse: High-performance OLAP engine that stores all reported event data and powers the dashboard’s real-time analytics
• Resend: External SMTP email service for sending account activation emails, etc.

Event Data Flow

When an SDK in your app reports an event, the data follows this path:

In short: every event sent by the SDK passes through Cloudflare for TLS termination and IP tagging, Nginx for header conversion, and Aptabase for validation and geo-resolution, before being written into ClickHouse in a structured format. All the charts and metrics you see on the dashboard are queried from ClickHouse in real time.

Conclusion

Aptabase itself is an excellent lightweight analytics tool, but the self-hosting documentation is fairly minimal, and there are several things you need to figure out on your own during deployment. Here’s a summary of the key gotchas:

1. No emails by default — activation links are in the container logs, check with docker logs -f
2. HTTPS is required — otherwise the auth flow loops endlessly; Cloudflare Tunnel is the recommended solution
3. Real IP resolution — after Cloudflare Tunnel proxying, you need an Nginx layer to convert headers
4. SMTP port — use 587 (STARTTLS), not 465; the latter may not work in Docker environments
5. Security configuration — always replace the default AUTH_SECRET and keep your API keys and database passwords safe

I hope this article helps anyone else looking to self-host Aptabase and saves you from some of these pitfalls.

官方提供了 Self-Hosting 仓库，看起来很简单 ——clone 下来、改改配置、docker compose up -d 就完事了。但实际部署过程中还是踩了不少坑，Issue 里也有很多人遇到了类似的问题。这里把我的经历整理出来，希望能帮到后来人。

坑一：默认不发邮件，激活链接藏在日志里

Aptabase 默认没有配置 SMTP，注册账号后不会收到任何邮件。但它会把激活链接打印在容器日志里，所以注册完之后需要手动查看日志来获取激活链接：

1

docker logs -f aptabase_app

在日志中找到类似下面的链接，复制到浏览器打开即可激活账号：

1

https://your-domain/api/_auth/continue?token=eyJhbGciOiJIUzI1NiIs...

当然这只是临时方案，后面我们会配置 SMTP 来让邮件正常发送。

坑二：必须配置 HTTPS，否则激活链接会循环跳转

拿到激活链接后点击，却发现页面一直循环跳转回登录页，始终无法完成激活。排查后发现，Aptabase 要求 BASE_URL 必须是 HTTPS，否则认证流程中的 Cookie 和重定向会出问题。

我的服务跑在家里的 Mac Mini 上，没有公网 IP，也不想折腾证书。最终的方案是使用 Cloudflare Tunnel + 自定义域名来解决。

配置 Cloudflare Tunnel

1. 登录 Cloudflare Dashboard，进入 Zero Trust → Networks → Tunnels
2. 点击 Create a tunnel，选择 Cloudflared 类型，给 Tunnel 起一个名字（比如 mac-mini）
3. 按照页面提示，在 Mac Mini 上安装并运行 cloudflared。macOS 上可以用 Homebrew：

1

brew install cloudflared

然后按照页面给出的命令连接 Tunnel（会包含一个 Token）：

1

cloudflared service install <your-token>

4. 在 Tunnel 的 Public Hostname 页面添加一条记录：
   • Subdomain：stats（或你喜欢的名字）
   • Domain：选择你在 Cloudflare 上托管的域名，比如 pastepaw.com
   • Service：http://localhost:3200（这里的端口对应 docker-compose 中 Nginx 映射的端口）

配置完成后，Cloudflare 会自动管理 HTTPS 证书，外部访问 https://stats.pastepaw.com 的流量会通过 Tunnel 安全地转发到你的 Mac Mini。

坑三：获取不到用户真实 IP

部署完成后发现 Dashboard 里所有用户的 IP 地址都一样 —— 显示的都是 Cloudflare 的 IP，而不是用户的真实 IP。

这是 Cloudflare Tunnel 的经典问题。流量经过 Cloudflare 代理后，到达你的服务时，来源 IP 变成了 Cloudflare 的服务器 IP。真正的用户 IP 被放在了 CF-Connecting-IP 这个 HTTP Header 里，但 Aptabase（基于 ASP.NET Core）默认不会读取这个 Header。

解决方案是在 Aptabase 前面加一层 Nginx，把 CF-Connecting-IP 转换为标准的 X-Forwarded-For，然后让 Cloudflare Tunnel 指向 Nginx 而非直接指向 Aptabase。

Nginx 配置文件 nginx.conf 如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

events {
    worker_connections 1024;
}

http {
    server {
        listen 80;

        location / {
            proxy_pass http://aptabase:8080;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $http_cf_connecting_ip;
            proxy_set_header X-Forwarded-For $http_cf_connecting_ip;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }
}

这样 Aptabase 就能正确识别到用户的真实 IP 了。

坑四：配置 SMTP 邮件发送

日志里翻激活链接终归不是长久之计。Aptabase 支持通过环境变量配置 SMTP，我这里选择了 Resend 作为邮件服务 —— 注册免费，每月有 3,000 封邮件的额度，对个人项目完全够用。

在 Resend 中绑定域名

1. 注册 Resend 账号
2. 进入 Domains 页面，点击 Add Domain
3. 输入你想用于发送邮件的域名（比如 mail.pastepaw.com，也可以和 Aptabase 的域名不同，没有关系）
4. Resend 会给你几条 DNS 记录需要添加，通常包括：
   • 一条 MX 记录
   • 一条 SPF（TXT）记录
   • 几条 DKIM（TXT）记录
5. 到你的 DNS 管理面板（比如 Cloudflare）中添加这些记录
6. 回到 Resend，点击 Verify，等待验证通过（通常几分钟内完成）

生成 API Key

1. 在 Resend 左侧菜单进入 API Keys 页面
2. 点击 Create API Key
3. 给 Key 起个名字（比如 aptabase），权限选择 Sending access，域名限制可以选择刚才绑定的域名
4. 复制生成的 Key（以 re_ 开头），这就是你的 SMTP 密码

配置环境变量

在 docker-compose.yml 的 Aptabase 服务中添加以下环境变量：

1
2
3
4
5

SMTP_HOST: smtp.resend.com
SMTP_PORT: 587
SMTP_USERNAME: resend
SMTP_PASSWORD: re_你的API_Key
SMTP_FROM_ADDRESS: noreply@mail.pastepaw.com

注意：这里端口要用 587（STARTTLS），而不是 465（Implicit TLS）。实测使用 465 端口在 Docker 环境下无法正常发送邮件，换成 587 后立刻恢复正常。这也是一个容易踩的坑。

完整的 Docker Compose 配置

以下是最终可用的完整 docker-compose.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

services:
  nginx:
    container_name: aptabase_nginx
    image: nginx:alpine
    restart: always
    depends_on:
      - aptabase
    ports:
      - 3200:80
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    mem_limit: 256m
    cpus: 0.5
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase_db:
    container_name: aptabase_db
    image: postgres:15-alpine
    restart: always
    mem_limit: 2g
    cpus: 2
    volumes:
      - ./db-data:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: aptabase
      POSTGRES_PASSWORD: ${PASSWORD}
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase_events_db:
    container_name: aptabase_events_db
    image: clickhouse/clickhouse-server:23.8.4.69-alpine
    restart: always
    mem_limit: 4g
    cpus: 2
    volumes:
      - ./events-db-data:/var/lib/clickhouse
    environment:
      CLICKHOUSE_USER: aptabase
      CLICKHOUSE_PASSWORD: ${PASSWORD}
    ulimits:
      nofile:
        soft: 262144
        hard: 262144
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

  aptabase:
    container_name: aptabase_app
    image: ghcr.io/aptabase/aptabase:main
    restart: always
    depends_on:
      - aptabase_events_db
      - aptabase_db
    mem_limit: 2g
    cpus: 2
    environment:
      BASE_URL: https://stats.pastepaw.com
      AUTH_SECRET: 替换为你自己的随机密钥
      DATABASE_URL: Server=aptabase_db;Port=5432;User Id=aptabase;Password=${PASSWORD};Database=aptabase
      CLICKHOUSE_URL: Host=aptabase_events_db;Port=8123;Username=aptabase;Password=${PASSWORD}
      SMTP_HOST: smtp.resend.com
      SMTP_PORT: 587
      SMTP_USERNAME: resend
      SMTP_PASSWORD: 替换为你的Resend_API_Key
      SMTP_FROM_ADDRESS: noreply@mail.pastepaw.com
    logging:
      driver: json-file
      options:
        max-size: 10m
        max-file: "3"

需要创建一个 .env 文件来存放数据库密码：

1

echo "PASSWORD=你的数据库强密码" > .env

提醒：AUTH_SECRET 务必替换为自己生成的随机字符串，可以在 RandomKeygen 上生成一个。不要使用官方文档里的示例值。

启动服务

1

docker compose up -d

等待所有容器启动完成后，访问 https://stats.pastepaw.com，注册账号，这次你应该能正常收到激活邮件了。

整体架构图

所有组件部署完成后，整体架构如下：

各组件职责：

• Cloudflare：提供 HTTPS 证书管理和 CDN 加速，通过 Tunnel 将外部流量安全地转发到家里的 Mac Mini
• Nginx：反向代理，核心作用是将 Cloudflare 注入的 CF-Connecting-IP Header 转换为 X-Forwarded-For，让 Aptabase 能识别用户真实 IP
• Aptabase：核心应用服务，处理 SDK 上报的事件、管理用户账号、提供 Dashboard
• PostgreSQL：存储用户账号、应用配置、API Key 等关系型数据
• ClickHouse：高性能 OLAP 引擎，存储所有上报的事件数据，支撑 Dashboard 的实时分析查询
• Resend：外部 SMTP 邮件服务，用于发送账号激活邮件等

事件数据流转

当 App 中的 SDK 上报一个事件时，数据会经过以下路径：

简单来说：SDK 发出的每一个事件，经过 Cloudflare 解密和 IP 标记、Nginx 的 Header 转换、Aptabase 的校验和地理解析后，最终以结构化的形式写入 ClickHouse。而你在 Dashboard 上看到的所有图表和指标，都是从 ClickHouse 中实时查询出来的。

总结

Aptabase 本身是一个非常优秀的轻量级统计工具，但 Self-Host 的文档相对简略，部署过程中有不少需要自己摸索的地方。总结一下关键的几个坑：

1. 默认不发邮件 —— 激活链接在容器日志里，需要 docker logs -f 查看
2. 必须 HTTPS—— 否则认证流程会循环跳转，推荐使用 Cloudflare Tunnel 解决
3. 真实 IP 获取 ——Cloudflare Tunnel 代理后需要加一层 Nginx 做 Header 转换
4. SMTP 端口 —— 用 587（STARTTLS）而不是 465，后者在 Docker 环境下可能不工作
5. 安全配置 —— 记得替换默认的 AUTH_SECRET，妥善保管 API Key 和数据库密码

希望这篇文章能帮到同样想 Self-Host Aptabase 的朋友，少走一些弯路。

技术书籍

技术书籍偏 C++ 以及一些底层的技术，英文为主。 选英文版主要原因有两个吧，一是有些书没有中文版，即便有，翻译的也很晦涩难懂，我倒不怪罪译者的水平，技术书籍确实比较难翻译得平易近人。（打比方说我比较敬仰的 C++ 骨灰级程序员 侯捷老师 的技术水平肯定是一流的，但是翻译的书也是很晦涩，可读性比较..）

1. Effective Modern C++
   
   Scott Meyer 著作，每次读都会有新的收获，技术点讲的非常的细，比如关于 std::move 和 universal reference 就花了一章来介绍，各种想不到的 case. C++ 真的是了解的越多，就发现不了解的更多。 建议阅读英文版。

2. Advanced C & C++ Compiling
   
   Milan Stevanovic 著作，讲解了一个程序的整个生命周期是怎么样的，静态库、动态库，静态链接、动态链接的细节实现等等，是一本修炼内功的一本好书。似乎也有中文版本，不确定翻译的怎么样。

3. C++ Move Semantics
   
   Nicolai M. Josuttis 在 2020 年出版的一本书。难以想象 C++11 带来的 move 竟然能写一本书。如果你对 Value category，move 语义，rvalue，perfect forwarding, universal reference 等概念有任何的疑问，或者想更深入地了解其中的内幕，那这本书基本能满足所有的想象。跳着读的，读了有 1/3 左右吧。

4. *OS internals Volume I - User Mode
   
   Jonathon Levin 写的三部曲中的第一部，也是 Mac Os x & ios Internals 的第二版，主要是讲除了 macOS 之外的苹果的操作系统，比如 iOS watchOS tvOS 等。苹果开发者修炼内功的一本书。

5. LLVM Techniques, Tips, and Best Practices
   
   Min-Yih Hsu 的一本书，2021 年出版，比较新，主要讲了 LLVM 的构建系统，clang 的架构，以及整个编译链的介绍，以及如何在每一环进行扩展，编写自己的工具。

   我比较感兴趣的是写 AST Matcher Plugin 来编写定制化的静态检查，以及 Pass Plugin 扩展 Pass 处理链条。基于前者实现了几个静态检查，比如使用 shared_ptr 的类构造中不允许调用 shared_from_this () 否则会报错。 还使用 PassPlugin 实现了一个简单的 AOP，通过拦截编译器生成的函数，注入函数调用指令，感兴趣的可以看看这里。

6. Learn LLVM 12
   
   Kai Nacke 2021 年的一本书，是上本书的姊妹篇。和上面那本相比，这里讲 IR 的比较多一些。看了有 1/3 吧，主要还是和上面的交叉互补着看。
   这两本书都是 Packt 家的书，正好春节的时候搞促销活动，$5 / 月 随便看，他们网站阅读非常好，比电子书体验好很多，比较推荐，有需要的可以关注。

媒体 & 杂志

• 媒体的话，只订阅了 NYTimes，新闻比较实时，有一些非常有见解的文章。但是有些方面还是屁股决定脑袋，所以难免，客观去看待吧。
• 杂志主要英文，主要是为了提高除技术之外的英文阅读能力，扩展一些视野。
  1. Scientific American 推荐指数 ⭐⭐⭐⭐⭐
     偏科技类的文章居多，目前是在淘宝上按半年订实体书。起源是这样的，本来是随便翻一翻，结果看了去年介绍 詹姆斯韦伯 望眼镜的一期，介绍的非常详细，收获很大，果断订了实体书。书的质量也很好，插图很精美，文章介绍的通俗易通，比抖音上各种科普视频强太多了。
  2. Reader’s Digest 推荐指数 ⭐⭐⭐
     适合没事儿时候翻翻，上面有一些有意思的小故事

但是最近考虑把服务器给退掉，所以 blog 的托管就成了一个问题。简单做了下调研，国内的云厂商基本都有，但是麻烦的是域名和备案。做了一些调研，最终考虑托管到 Cloudflare Pages 上，有以下几个优势：

1. 非常简单，基本就是点一点就能全部搞定。把 blog 从我自己机器切换到 Cloudflare 上过程可能都不到 10 分钟，就完全可以访问. (如果是用 GitHub actions 生成静态页面的话，配置 workflow 需要多花半个小时左右)
2. 对技术人来说很友好。Cloudflare Pages 直接读取 Github 上 blog 的私有仓库，我本地有修改的话，直接 push 到 Github 即可， Cloudflare Pages 会自动拉取
3. 静态资源访问免费，Functions 和 Works 每天有 10w 次的免费访问
4. 我的域名解析也在 Cloudflare 上面，支持直接 cname 到生成的二级域名上，自动处理 htttps 证书的问题，也很省心
5. 可以很方便地结合 Cloudflare 提供的其他能力，比如认证、Functions 等等..

整体的结构图如下：

整个流程是这样的：

1. 添加新的文档或者页面，并 push 到 GitHub 上我的 blog 仓库
2. commit 触发 GitHub Action，Action 会搭建 hexo 的环境，并执行 hexo generate 生成静态网站
3. Action 会把静态网站的修改生成新的 commit，并 push 到 public_blog 仓库，也就是静态网站的仓库
4. Cloudflare 会去 public_blog 仓库拉取最新的提交，并部署到 CDN 和边缘节点上。

Have fun!

Ref:
Cloudflare Pages 介绍文档

从上篇文章中我们也了解到，对一个内存地址的读 和 写操作：

1
2

*address = ...;  // 写操作
... = *address;  // 读操作

当开启 Address Sanitizer 之后， 运行时库将会替换掉 malloc 和 free 函数，在 malloc 分配的内存区域前后设置 “投毒”(poisoned) 区域，使用 free 释放之后的内存也会被隔离并投毒，poisoned 区域也被称为 redzone。

上面的内存地址访问的代码，编译器会帮我们修改为这样的代码：

1
2
3
4

if (IsPoisoned(address)) {
  ReportError(address, kAccessSize, kIsWrite);
}
*address = ...;  // or: ... = *address;

这样对内存的访问，编译器会在编译期自动在所有内存访问之前通过判断 IsPoisoned(address) 做一下 check 是否被 “投毒”。

那么实现且高效地实现 IsPoisoned ()，并使得 ReportError () 函数比较紧凑就十分重要。

在深入了解之前，我们先了解 Shadow 内存，以及主应用内存区和 shadow 内存映射。

Shadow 内存 & 主应用内存区和 shadow 内存间的映射

首先，虚拟内存地址被分配了两段不连续的区域：主应用内存区 和 shadow 内存区域。
主应用内存区（Main Application Memory, or Mem for short)，其实就是在应用里分配的常规内存。
Shadow 内存区，它包含了主内存区状态的 meta 信息，也称之为 shadow value（影子值）。主应用内存区和 shadow 内存区有一个映射关系，当应用内存被 “投毒”（poisoned），会在 shadow 内存区记录一个值作为体现。这样就可以通过查询 shadow 内存区的值，来判断应用内存是否被 “投毒”。

更细一点来说，内存地址会分配 5 部分，最上和最下 (HighMem & LowMem) 都是应用内存区，他们会映射到 HighShadow 和 LowShadow 上，HighShadow 和 LowShadow 之间是 ShadowGap 区域，ShadowGap 区域是不可访问的，如果访问到会直接 crash.

为了节省内存占用，AddressSanitizer 会把 8 bytes 的应用内存会映射到 1 byte 的 shadow 内存。
因此，HighMem + LowMem 占整体的 7/8，剩余 1/8 分配给 shadow 和 shadow gap.

从应用内存地址到 Shadow 内存地址映射算法是这样的：

1

Shadow = (Mem >>3) + Offset

查看 LLVM 的源码可以发现 offset 值因平台而异，这里就以 0x7fff8000 (1 << 46) 为例。

1

Shadow = (Mem >> 3) + 0x7fff8000;

映射图如下：

Shadow 内存的 9 种状态

这 1byte 的 shadown 内存会有 9 种值对应应用内存的状态：

• 负值，当 8 字节的应用内存全都被 poisoned 时；
• 0 值，当且仅当 8 字节的应用内存都没有被 poisoned 时；
• 1-7 值，为 k 的意思为 “前 k 个字节都没有被 poisoned，后 8-k 个字节被 poisoned”，这个是由 malloc 分配的内存总是 8 字节对齐作为前提来作为保证的。这样的话，当 malloc(13) 时，得到的是前一个 完整的 qword（8 字节，未被 poisoned）加上后一个 qword 的前 5 个 byte（未被 poisoned）

如何检查是否在 “投毒区”（poisoned/redzone）？

这样的话，我们就可以根据 shadow 内存的 9 种值来判断 引用内存的状态 了。

1
2
3

if (IsPoisoned(address)) {
  ReportError(address, kAccessSize, kIsWrite);
}

扩展为：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// 拿到主应用内存地址对应的 Shadow 内存地址
byte *shadow_address = MemToShadow(address);

// 检查 shadow 内存值，如果为 0，肯定没有被 poison，因为可以跳过
// 如果不为 0，需要进一步检查是否访问的字节是否被 poisoned
byte shadow_value = *shadow_address;
if (shadow_value) {
  // 进一步检查访问的内存大小是否被 poisoned
  if (SlowPathCheck(shadow_value, address, kAccessSize)) {
    ReportError(address, kAccessSize, kIsWrite);
  }
}

// Check the cases where we access first k bytes of the qword
// and these k bytes are unpoisoned.
bool SlowPathCheck(shadow_value, address, kAccessSize) {
  last_accessed_byte = (address & 7) + kAccessSize - 1;
  return (last_accessed_byte >= shadow_value);
}

SlowPathCheck () 里，检查是否当前访问的地址的前若干个字节是否被 poisoned 了，因为是 8bytes 的应用内存映射到 1byte 的 shadow 上，首先要知道偏移，偏移 + 长度就是最后一个字节的位置，shadow_value <= 这个位置 - 1，说明被投毒了。

来看个例子。

比如应用内存 0x1000 - 0x1007 对应 shadow 的 0xF000 的地址

1

0x1000, 0x1001, 0x1002, 0x1003, 0x1004, 0x1005, 0x1006, 0x1007,

如果 0xF000 的值为 2， 就说明 0x1000, 0x1001 未被 poisoned，0x1002 到 0x1007 是被 poisoned 的。

那么，如果有一个 int 值在 0x1002 上，长度是 4 字节，那么我就需要检查 0x1005 以及之前（也就是前 6 个字节）是否被投毒，也就是检查 shadow value 是否 <= 5，如果小于等于 5，就说明只有前 5 个或者更少未被 poisoned，第 6 个字节一定被 poisoned 了，也就是这个 int 值肯定是被 poisoned 了。

再来看计算公式：
last_accessed_byte = 0x1002 & 7 + 4 - 1 = 5,
如果 5 >= shadow value, 即认为被 poisoned，和上述解释是一致的。

LLVM 里的实现源码

实际上，LLVM 是通过自定义 LLVM Pass 来插入指令并配合运行时库来完成上面的操作的。
具体的源码可以参考 AddressSanitizer.cpp

源码超级长，我们只挑和上面相关的，首先定义了 static const uint64_t kDefaultShadowScale = 3;
， 1 << 3 == 8，因此就作为映射的粒度。

AddressSanitizerLegacyPass 继承自 FunctionPass，override 了 runOnFunction(Function &F)，也就可以对所有的函数进行修改和操作。runOnFunction 实现内部，创建了 AddressSanitizer 的实例，并调用了其 instrumentFunction(F, TLI) 方法。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

class AddressSanitizerLegacyPass : public FunctionPass {
public:
  static char ID;

  explicit AddressSanitizerLegacyPass(
      bool CompileKernel = false, bool Recover = false,
      bool UseAfterScope = false,
      AsanDetectStackUseAfterReturnMode UseAfterReturn =
          AsanDetectStackUseAfterReturnMode::Runtime)
      : FunctionPass(ID), CompileKernel(CompileKernel), Recover(Recover),
        UseAfterScope(UseAfterScope), UseAfterReturn(UseAfterReturn) {
    initializeAddressSanitizerLegacyPassPass(*PassRegistry::getPassRegistry());
  }

  // ...

  bool runOnFunction(Function &F) override {
    GlobalsMetadata &GlobalsMD =
        getAnalysis<ASanGlobalsMetadataWrapperPass>().getGlobalsMD();
    const StackSafetyGlobalInfo *const SSGI =
        ClUseStackSafety
            ? &getAnalysis<StackSafetyGlobalInfoWrapperPass>().getResult()
            : nullptr;
    const TargetLibraryInfo *TLI =
        &getAnalysis<TargetLibraryInfoWrapperPass>().getTLI(F);

    //️ ⬇️️️⬇️⬇️
    AddressSanitizer ASan(*F.getParent(), &GlobalsMD, SSGI, CompileKernel,
                          Recover, UseAfterScope, UseAfterReturn);
    return ASan.instrumentFunction(F, TLI);
  }

AddressSanitizer::instrumentFunction 内容很长，

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

bool AddressSanitizer::instrumentFunction(Function &F,
                                          const TargetLibraryInfo *TLI) {
  ...

  // We want to instrument every address only once per basic block (unless there
  // are calls between uses).
  SmallPtrSet<Value *, 16> TempsToInstrument;
  SmallVector<InterestingMemoryOperand, 16> OperandsToInstrument;
  SmallVector<MemIntrinsic *, 16> IntrinToInstrument;
  SmallVector<Instruction *, 8> NoReturnCalls;
  SmallVector<BasicBlock *, 16> AllBlocks;
  SmallVector<Instruction *, 16> PointerComparisonsOrSubtracts;


  // Fill the set of memory operations to instrument.
  // 遍历 函数里的每一个 block
  for (auto &BB : F) {
    AllBlocks.push_back(&BB);
    TempsToInstrument.clear();
    int NumInsnsPerBB = 0;

    // 遍历 block 里的每一条指令 (Instruction)
    for (auto &Inst : BB) {
      if (LooksLikeCodeInBug11395(&Inst)) return false;
      SmallVector<InterestingMemoryOperand, 1> InterestingOperands;

      🌟🌟🌟
      // 寻找感兴趣的内存操作数（store/load，那他们的操作数当然也就是内存地址了）
      getInterestingMemoryOperands(&Inst, InterestingOperands);

      if (!InterestingOperands.empty()) {
        for (auto &Operand : InterestingOperands) {
          ...
          // 存到 vector 里
          OperandsToInstrument.push_back(Operand);
          NumInsnsPerBB++;
        }
      }
      ...
    }
  }
  ...
  // Instrument.
  int NumInstrumented = 0;
  for (auto &Operand : OperandsToInstrument) {
    if (!suppressInstrumentationSiteForDebug(NumInstrumented))
      🌟🌟🌟
      // 对于找到的指令进行修改
      instrumentMop(ObjSizeVis, Operand, UseCalls,
                    F.getParent()->getDataLayout());
    FunctionModified = true;
  }

  ...

  LLVM_DEBUG(dbgs() << "ASAN done instrumenting: " << FunctionModified << " "
                    << F << "\n");

  return FunctionModified;
}

AddressSanitizer::getInterestingMemoryOperands() 判断传入的指令 I 是否为感兴趣的 load 和 store 指令，把指令和地址信息放入 Interesting vector 里。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

void AddressSanitizer::getInterestingMemoryOperands(
    Instruction *I, SmallVectorImpl<InterestingMemoryOperand> &Interesting) {
  // 判断是否 Load 指令
  if (LoadInst *LI = dyn_cast<LoadInst>(I)) {
    if (!ClInstrumentReads || ignoreAccess(I, LI->getPointerOperand()))
      return;
    Interesting.emplace_back(I, LI->getPointerOperandIndex(), false,
                             LI->getType(), LI->getAlign());
  // 判断是否 Store 指令
  } else if (StoreInst *SI = dyn_cast<StoreInst>(I)) {
    if (!ClInstrumentWrites || ignoreAccess(I, SI->getPointerOperand()))
      return;
    Interesting.emplace_back(I, SI->getPointerOperandIndex(), true,
                             SI->getValueOperand()->getType(), SI->getAlign());
  } else if (AtomicRMWInst *RMW = dyn_cast<AtomicRMWInst>(I)) {
    ....

AddressSanitizer::instrumentMop()

Calls

void doInstrumentAddress()

Calls

AddressSanitizer::instrumentAddress() 是插入前面提到的内存判断的地方，函数比较长，这里省略掉不太影响理解的代码。
这里的参数 InsertBefore 指令就是前面找到的 load/store 指令。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

void AddressSanitizer::instrumentAddress(Instruction *OrigIns,
                                         Instruction *InsertBefore, Value *Addr,
                                         uint32_t TypeSize, bool IsWrite,
                                         Value *SizeArgument, bool UseCalls,
                                         uint32_t Exp) {
  Value *AddrLong = IRB.CreatePointerCast(Addr, IntptrTy);

  Type *ShadowTy =
      IntegerType::get(*C, std::max(8U, TypeSize >> Mapping.Scale));
  Type *ShadowPtrTy = PointerType::get(ShadowTy, 0);

  // 🌟🌟🌟
  // 计算出 shadow 地址
  Value *ShadowPtr = memToShadow(AddrLong, IRB);
  // 0
  Value *CmpVal = Constant::getNullValue(ShadowTy);
  // Load shadow 值
  Value *ShadowValue =
      IRB.CreateLoad(ShadowTy, IRB.CreateIntToPtr(ShadowPtr, ShadowPtrTy));

  // 🌟🌟🌟
  // 创建比较指令，shadow_value != 0
  Value *Cmp = IRB.CreateICmpNE(ShadowValue, CmpVal);
  size_t Granularity = 1ULL << Mapping.Scale;
  Instruction *CrashTerm = nullptr;

  if (ClAlwaysSlowPath || (TypeSize < 8 * Granularity)) {
    // We use branch weights for the slow path check, to indicate that the slow
    // path is rarely taken. This seems to be the case for SPEC benchmarks.
    Instruction *CheckTerm = SplitBlockAndInsertIfThen(
        Cmp, InsertBefore, false, MDBuilder(*C).createBranchWeights(1, 100000));
    assert(cast<BranchInst>(CheckTerm)->isUnconditional());
    BasicBlock *NextBB = CheckTerm->getSuccessor(0);
    IRB.SetInsertPoint(CheckTerm);

    // 🌟🌟🌟
    // SlowPathCmp
    Value *Cmp2 = createSlowPathCmp(IRB, AddrLong, ShadowValue, TypeSize);
    if (Recover) {
      CrashTerm = SplitBlockAndInsertIfThen(Cmp2, CheckTerm, false);
    } else {
      BasicBlock *CrashBlock =
        BasicBlock::Create(*C, "", NextBB->getParent(), NextBB);
      CrashTerm = new UnreachableInst(*C, CrashBlock);
      BranchInst *NewTerm = BranchInst::Create(CrashBlock, NextBB, Cmp2);
      ReplaceInstWithInst(CheckTerm, NewTerm);
    }
  } else {
    CrashTerm = SplitBlockAndInsertIfThen(Cmp, InsertBefore, !Recover);
  }

  Instruction *Crash = generateCrashCode(CrashTerm, AddrLong, IsWrite,
                                         AccessSizeIndex, SizeArgument, Exp);
  Crash->setDebugLoc(OrigIns->getDebugLoc());
}

看一下 AddressSanitizer::memToShadow() 的实现：
Mapping.Scale 上面提过是 3，注释好评，这里其实是创建了两条指令，一条是 Shadow >> scale, 然后和 Offset 相或，最终就是 Shadow >> scale | offset.
这里的 offset 在不同平台上数值是不同的，并非固定值，有兴趣的可以查看该文件的最上面的常量定义。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Value *AddressSanitizer::memToShadow(Value *Shadow, IRBuilder<> &IRB) {
  // Shadow >> scale， CreateLShr 创建右移的指令
  Shadow = IRB.CreateLShr(Shadow, Mapping.Scale);
  if (Mapping.Offset == 0) return Shadow;
  // (Shadow >> scale) | offset
  Value *ShadowBase;
  if (LocalDynamicShadow)
    ShadowBase = LocalDynamicShadow;
  else
    ShadowBase = ConstantInt::get(IntptrTy, Mapping.Offset);
  if (Mapping.OrShadowOffset)
    // 创建 “或” 指令
    return IRB.CreateOr(Shadow, ShadowBase);
  else
    return IRB.CreateAdd(Shadow, ShadowBase);
}

Value *AddressSanitizer::createSlowPathCmp()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

Value *AddressSanitizer::createSlowPathCmp(IRBuilder<> &IRB, Value *AddrLong,
                                           Value *ShadowValue,
                                           uint32_t TypeSize) {
  size_t Granularity = static_cast<size_t>(1) << Mapping.Scale;
  // Addr & (Granularity - 1)
  Value *LastAccessedByte =
      IRB.CreateAnd(AddrLong, ConstantInt::get(IntptrTy, Granularity - 1));
  // (Addr & (Granularity - 1)) + size - 1
  if (TypeSize / 8 > 1)
    LastAccessedByte = IRB.CreateAdd(
        LastAccessedByte, ConstantInt::get(IntptrTy, TypeSize / 8 - 1));
  // (uint8_t) ((Addr & (Granularity-1)) + size - 1)
  LastAccessedByte =
      IRB.CreateIntCast(LastAccessedByte, ShadowValue->getType(), false);
  // ((uint8_t) ((Addr & (Granularity-1)) + size - 1)) >= ShadowValue
  return IRB.CreateICmpSGE(LastAccessedByte, ShadowValue);
}

Ref & 扩展阅读

1. AddressSanitizerAlgorithm
2. Finding races and memory errors with LLVM instrumentation - Konstantin Serebryany, Google on 2011 LLVM Developers’ Meeting
3. LLVM AddressSanitizer source code

LLVM 提供了一系列的工具帮助 C/C++/Objc/Objc++ 开发者检查代码中可能的潜在问题，这些工具包括 Address Sanitizer，Memory Sanitizer，Thread Sanitizer，XRay 等等，功能各异。

本篇主要介绍可能是最常用的一个工具 Address Sanitizer，它的主要作用是帮助开发者在运行时检测出内存地址访问的问题，比如访问了释放的内存，内存访问越界等。

全部种类如下，也都是非常常见的几类内存访问问题。

这里为了便于理解，先介绍一下大概的工作原理。然后从上面几种场景中挑出几个有代表性的介绍一下。

Address Sanitizer 的基本工作原理

我们对一个内存地址的 访问 无外乎两种操作：读 和 写，也就是

1
2

*address = ...;  // 写操作
... = *address;  // 读操作

Address Sanitizer 的工作依赖编译器运行时库，当开启 Address Sanitizer 之后， 运行时库将会替换掉 malloc 和 free 函数，在 malloc 分配的内存区域前后设置 “投毒”(poisoned) 区域，使用 free 释放之后的内存也会被隔离并投毒，poisoned 区域也被称为 redzone。

这样对内存的访问，编译器会在编译期自动在所有内存访问之前做一下 check 是否被 “投毒”。所以以上的代码，就会被编译器改成这样：

1
2
3
4
5

if (IsPoisoned(address)) {
  ReportError(address, kAccessSize, kIsWrite);
}
*address = ...;  // or: ... = *address;

这样的话，当我们不小心访问越界，访问到 poisoned 的内存（redzone），就会命中陷阱，在运行时 crash 掉，并给出有帮助的内存位置的信息，以及出问题的代码位置，方便开发者排查和解决。

Note: 从基本工作原理来看，我们可以获知，打开 Address Sanitizer 会增加内存占用，且因为所有的内存访问之前都会有 check 是否访问了 “投毒” 区域的内存，会有额外的运行开销，对运行性能造成一定的影响，因此通常只在 Debug 模式或测试场景下打开

更详细的原理参考第二篇 Address Sanitizer 实现原理

如何开启 Address Sanitizer

默认 clang 是不打开 Address Sanitizer 的，需要增加 -fsanitize=address -g 参数，-g 用来在出现问题的报告中，增加有助于 debug 的信息，比如出问题的代码位置和行数等，非常建议带上。

如何使用我们在下个例子里进行展示。

分析一个 Use after free 的 case

来看一个简单的例子，test_use_after_free.c 文件有以下内容：

1
2
3
4
5
6
7
8

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

int main(int argc, char *argv[]) {
  int *p = malloc(sizeof(int));
  free(p);
  return *p;  // 访问了已经释放的内存地址
}

这段代码很简单，在堆上创建了一块 int 大小的内存，随后释放，然后 *p 来读取位于 p 内存地址的值，显然是有问题的。实际场景往往会更杂，free 的位置和访问的位置可能离得很远，不容易发现，而且编译期并不会提示错误。

编译：

1

clang -fsanitize=address -g test_use_after_free.c -o use_after_free

运行之后 crash，并提供给我们一些错误信息：

这些错误信息很重要，可以协助我们排查出现问题的位置。我们从上往下看，第一行告诉我们了内存地址访问错误类型为 heap-use-after-free，并给出了地址和寄存器的值：

1

==65906==ERROR: AddressSanitizer: heap-use-after-free on address 0x000105000730 at pc 0x000102c57f48 bp 0x00016d1ab190 sp 0x00016d1ab188

接下来就是告诉我们是在 test_use_after_free.c 文件的 第 7 行 Read 时出的问题，也就是 return *p 时出现的问题。
接着就是该内存区域是在哪里释放的，就是第 6 行，以及之前在哪里分配的，也就是第 5 行。 可以说非常清晰。

接下来就是 Shadow 的 bytes，具体这里先按下不表，放到下篇具体实现原理里来具体解释。从图上我标记的箭头可以看出访问的是一块已经释放的堆内存。

Heap buffer overflow 堆内存溢出的 case

1
2
3
4
5
6
7
8

// heap-buffer-overflow.cpp
int main(int argc, char **argv) {
  int *array = new int[100];
  array[0] = 0;
  int res = array[100];  // 内存地址访问越界
  delete [] array;
  return res;
}

编译，这里用的是 C++，因此加上 -lc++ 来使用 libc++ 库

1

clang -fsanitize=address -g -lc++ test_heap_buffer_overflow.cpp -o heap_buffer_overflow

运行 & 错误信息：

分析：
第一行告诉我们错误类型为 heap-buffer-overflow，访问出错的内存地址为 0x00010613a7d4, 我们先记下来。

然后告诉我们是第 5 行的 读操作 导致的，也就是 int res = array[100]; 这里。

接下来的信息是告诉我们出现错误读操作的内存地址 0x00010613a7d4 是位于 400 bytes 内存的右边 4 个 byte 的位置，根据代码，我们知道这 400bytes，其实就是代码中创建的 100 个 int 值所在的内存地址。

1
2
3
4
5

0x00010403a7d4 is located 4 bytes to the right of 400-byte region [0x00010403a640,0x00010403a7d0)
allocated by thread T0 here:
    #0 0x1025de018 in wrap__Znam+0x74 (libclang_rt.asan_osx_dynamic.dylib:arm64e+0x4e018)
    #1 0x1021d3e6c in main test_heap_buffer_overflow.cpp:3
    #2 0x193e4be4c  (<unknown module>)

但实际中往往更复杂，访问的内存可能是距离很远的一块内存上，虽然也可以从这段错误信息里的 allocated by 的堆栈中找到实际分配这块的内存地址的位置，但是可能跟这个访问地址并没有什么关联，要注意辨别。

我们来这样模拟一下，在 array 后面再创建一个 array2，分配 100 个 int 的空间，然后访问 array 的时候，让其越界到 array2 的后面。为了方便查看，我们这里打印出来 array 和 array2 的内存地址范围。

1
2
3
4
5
6
7
8
9
10
11

#include <cstdio>
int main(int argc, char **argv) {
  int *array = new int[100];
  printf("array: %p\n", array);
  array[0] = 0;
  int *array2 = new int[100];
  printf("array2: %p\n", array2);
  int res = array[(array2-array + 100)];  // 首先肯定是越界了，甚至越界到 array2 的右边区域了
  delete [] array;
  return res;
}

我们来看下错误信息：

第二段错误信息里，相当于告诉我们访问的这块内存位于 array2 的紧挨着的右边的位置，但是这个内存位置其实和访问出错并无关系，此时，这个位置信息价值就不大了，应该参考第一段错误信息（红框位置），根据出现访问问题的源代码位置来分析即可，第二段相当于一个辅助的信息。

Note:
到这里大家可能会思考一个问题，如果上面访问 array 的代码，正好越界到 array2 的地址合法范围内，比如，int res = array[(array2-array + 1)], 会不会被检测到并 crash 呢？
很遗憾，这种 case 虽然越界了，但根据前面的运行原理来看，访问的内存区域并未被 “投毒”（poisoned），因此不会被检测到越界，也不会 crash。

最后我们再看一个检查内存泄漏的 case。

分析一个 Memory leak 的 case

我们在 test_memory_leak.cpp 模拟一个 leak:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

#include <stdlib.h>

class BadClass {
public:
  BadClass(int value): value_(new int(value)) {}
  ~BadClass() {
    // 没有 delete value_ 导致泄漏
  }

private:
  int *value_;
};

int main() {
  BadClass *bad = new BadClass(10);
  delete bad;
  return 0;
}

Note:
Memory leak 检测目前不支持 ARM，因此 M1 芯片的 MBP 也是不支持的，运行时会出现以下的错误提示。

1 2 3

ASAN_OPTIONS=detect_leaks=1 ./test_memory_leak.out ==39355==AddressSanitizer: detect_leaks is not supported on this platform. [1] 39355 abort ASAN_OPTIONS=detect_leaks=1 ./test_memory_leak.out

这里我在 X86_64 的 Linux 机器上进行测试。

编译：

1

clang -fsanitize=address -g -lstdc++ test_memory_leak.cpp -o test_memory_leak

运行：

1
2
3
4

# LeakSanitizer 在 X86 的 linux 上开启 Address Sanitizer 时默认打开的，因此直接运行即可
./test_memory_leak
# 如果是 Intel 版本的 macos，默认没有打开 LeakSanitizer，需要在运行前面增加一个环境变量来开启
ASAN_OPTIONS=detect_leaks=1 ./test_memory_leak

运行结果：

第一行告诉我们检测到了内存泄露，然后告诉我们泄漏了一个对象，共 4 个字节。泄漏的的位置是在 test_memory_leak.cpp 文件的第 15 行。

Summary

内存问题是 C/C++ 项目中比较头疼的问题，为了解决这类的问题，本篇文章主要介绍了 LLVM 的 Address Sanitizer 工具，以及基本的工作的原理；接着分析了 C/C++ 中几种常见的内存地址访问错误的 case，以及如何从错误信息中提取关键的信息进行排查问题。

其余的几种内存问题，大家可以自行模拟来尝试，非常建议在开发阶段 Debug 或者测试场景中打开 Address Sanitizer 提前暴露很多内存问题。

Ref & 扩展阅读

1. Google AddressSanitizer Wiki

2. Hardware-assisted AddressSanitizer

使用 case 如下图：

C++ Lambda 的函数结构

1

[capture_list](parameter_list) -> return_type {function_body}

其中，capture_list 表示捕获列表，parameter_list 表示函数参数列表，return_type 表示函数返回类型，function_body 表示函数体。下面是一个简单的 Lambda 函数示例，这里定义一个计算面积的名为 area 的 lambda。

1
2
3
4
5
6
7
8

#include <iostream>
int main() {
  double pi = 3.14;
  auto area = [=](double radius) -> double {
    return pi * radius * radius;
  };
  std::cout << "area of circle with radius 2.0 : " <<  area(2.0) << std::endl;
}

这里选择了 by-copy (=) 的方法来捕获 pi 这个变量，也就是会复制一份 pi 进到 area lambda 里，那么这个值 copy 到了哪里呢？

Lambda 在编译期的实现

我们使用 C++ insights 来看一下内部可能的实现：

实际编译器会为每一个 lambda 生成唯一的类（functor），有以下的特点：

1. line 6, 生成的类名唯一，不可读，不同编译器生成的名字可能不一样，我们在运行时是无法拿到具体类名的
2. line 9, 因为有 operator() 所以是可以直接当成函数调用的，函数参数和返回值和 lambda 中声明的完全一致。
3. line 15, 捕获的变量在这里，会被转化为类该类的属性，并在构造的传入捕获的参数 (line 15 & line 24)

ps: 其实也可见 C++ 中 lambda 的实现和 Java 的 lambda 转换为匿名内部类的实现，以及 Objective-C 的 block 的实现原理和变量捕获机制都非常的相似。

关于 const

如果我们将上例中的 area lambda 改成下面会如何？

1
2
3
4

auto area = [=](double radius) -> double {
  pi *= 2;
  return pi * radius * radius;
};

实际上编译会失败，clang 会报以下错误：

1
2
3
4

lambda.cpp:6:8: error: cannot assign to a variable captured by copy in a non-mutable lambda
    pi *= 2;
    ~~ ^
1 error generated.

这里最主要的原因是编译器生成的匿名类的 operator() 都是 const 的，const 在这里修饰 this 指针 (__lambda_5_15 对象的指针），表示 this 不可变，因此不可以修改属性 pi 的值。这一点稍微有点违反直觉，需要注意。

也即是说编译器意欲生成的代码是这样的，但发现不合法：

1
2
3
4
5
6
7
8

public:
  inline /*constexpr */ double operator()(double radius) const
  {
    pi *= 2;
    return (pi * radius) * radius;
  }
private:
  double pi;

那如何把 const 去掉，使得 lambda 内可以修改捕获的值呢？
答案就是 mutable 关键字，增加 mutable 之后：

1
2
3
4

auto area = [=](double radius) mutable -> double {
  pi *= 2;
  return pi * radius * radius;
};

再来看看生成后的 operator(), 没有了 const，也可以正常修改 this 的属性 pi

1
2
3
4
5
6
7
8
9

public:
  inline /*constexpr */ double operator()(double radius)
  {
    pi = pi * 2;
    return (pi * radius) * radius;
  }

private:
  double pi;

变量捕获方式 & 如何捕获 this 指针

捕获方法分为两种 = 和 &，分别对应 capture by-copy 和 capture by-reference, 基本的部分这里我们不多做介绍。需要注意的是对 this 的捕获，通过 [&] 和 [=] 对 this 的隐式捕获，以及 [this] 显式捕获都是 by-reference 的，其实捕获的都是 this 指针。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

#include <iostream>
using namespace std;

class Math {
public:
  Math(double value): value_(value) {}
auto square() {
return [&]() -> double {
return value_ * value_;
};
}
private:
double value_;
};

int main() {
Math math(10);
std::cout << math.square()() << std::endl;
}

return [&]() -> double ... 这里换成 [=] 或者 [this] 生成的代码都是完全一致的，如下：

捕获 this 指针 by-refernce 的好处是减少内存的 copy，但处理不当的话，比如 this 指针的生命周期如果没有 lambda 长，那么就会访问的野指针，导致 crash。这种 case 下，可以考虑通过 [*this] 的方式，copy this 对象到 lambda 中。 ps: [*this] 是 C++ 17 引入的。

方框的位置是和上面 by-reference 不同之处，会调用 Math 的 copy 构造创建一个 copy 保存到 lambda 对象中。

需要注意的是，即便是 copy 一份，因为生成的 operation () 还是 const 的，所以并不能修改 Math 的属性，如果需要修改，需要加上 mutable 关键字。

实际场景中，应该根据实际的需要（主要考虑生命周期），来选择是使用 by-copy 还是 by-reference 来捕获 this.

回顾 & 总结

1. lambda 本质上其实就是使用一个匿名的 functor（带有 operator() 的 class），并把 capture 的变量作为该类的属性
2. lambda 默认生成的 operator() 是 const，如果需要修改 capture 的变量副本，需要加 mutable 关键字修饰
3. 通过 [=] [&] 隐式捕获 还是 [this] 显式捕获 this 都是 by-reference 的，只有 [*this] 是 by-copy 的。注意实现的区别，以及如何进行选择。

Ref:

1. Lambdas, how to capture everything and stay sane - Dawid Zalewski (Meeting C++ 2022 on Youtube)
2. Lambda expressions (CppReference)

在讨论之前，我们先理清楚这样的一个简单但却容易混淆的逻辑。 std::shared_ptr 是个类模版，无法孤立存在的，因此实际使用中，我们都是使用他的具体模版类。这里使用 std::shared_ptr 来举例，我们讨论的时候，其实上是在讨论 std::shared_ptr 的线程安全性，并不是 SomeType 的线程安全性。

那我们在讨论某个操作是否线程安全的时候，也需要看具体的代码是作用在 std::shared_ptr 上，还是 SomeType 上。

举个例子:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

#include <memory>

struct SomeType {
  void DoSomething() {
    some_value++;
  }

  int some_value;
};

int main() {
  std::shared_ptr<SomeType> ptr;
  ptr->DoSomething();
  return 0;
}

这里例子中，如果 ptr->DoSomething () 是运行在多线程中，讨论它是否线程安全，如何进行判断呢？

首先它可以展开为 ptr.operator->()->DoSomething()，拆分为两步：

1. ptr.operator->() 这个是作用在 ptr 上，也就是 std::shared_ptr 上，因此要看 std::shared_ptr->() 是否线程安全，这个问题后面会详细来说
2. ->DoSomething () 是作用在 SomeType* 上，因此要看 SomeType::DoSomething () 函数是否线程安全，这里显示是非线程安全的，因为对 some_value 的操作没有加锁，也没有使用 atomic 类型，多线程访问就出现未定义行为（UB）

std::shared_ptr 线程安全性

我们来看看 cppreference 里是怎么描述的:

All member functions (including copy constructor and copy assignment) can be called by multiple threads on different instances of shared_ptr without additional synchronization even if these instances are copies and share ownership of the same object.

If multiple threads of execution access the same instance of shared_ptr without synchronization and any of those accesses uses a non-const member function of shared_ptr then a data race will occur; the shared_ptr overloads of atomic functions can be used to prevent the data race.

我们可以得到下面的结论：

1. 多线程环境中，对于持有相同裸指针的 std::shared_ptr 实例，所有成员函数的调用都是线程安全的。
   • 当然，对于不同的裸指针的 std::shared_ptr 实例，更是线程安全的
   • 这里的 “成员函数” 指的是 std::shared_ptr 的成员函数，比如 get ()、reset ()、 operrator->() 等）
2. 多线程环境中，对于同一个 std::shared_ptr 实例，只有访问 const 的成员函数，才是线程安全的，对于非 const 成员函数，是非线程安全的，需要加锁访问。

首先来看一下 std::shared_ptr 的所有成员函数，只有前 3 个是 non-const 的，剩余的全是 const 的：

我们来看两个例子
例 1:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include <iostream>
#include <memory>
#include <thread>
#include <vector>
#include <atomic>
using namespace std;

struct SomeType {
  void DoSomething() {
    some_value++;
  }

  int some_value;
};

int main(int argc, char *argv[]) {
  auto test = std::make_shared<SomeType>();
  std::vector<std::thread> operations;
  for (int i = 0; i < 10000; i++) {
    std::thread([=]() mutable {  //<<--
      auto n = std::make_shared<SomeType>();
      test.swap(n);
    }).detach();
  }

  using namespace std::literals::chrono_literals;
  std::this_thread::sleep_for(5s);
  return 0;
}

例 2:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#include <iostream>
#include <memory>
#include <thread>
#include <vector>
#include <atomic>
using namespace std;

struct SomeType {
  void DoSomething() {
    some_value++;
  }

  int some_value;
};

int main(int argc, char *argv[]) {
  auto test = std::make_shared<SomeType>();
  std::vector<std::thread> operations;
  for (int i = 0; i < 10000; i++) {
    std::thread([&]() mutable {  // <<---
      auto n = std::make_shared<SomeType>();
      test.swap(n);
    }).detach();
  }

  using namespace std::literals::chrono_literals;
  std::this_thread::sleep_for(5s);
  return 0;
}

这两个的区别只有传入到 std::thread 的 lambda 的捕获类型，一个是 capture by copy, 后者是 capture by reference，哪个会有线程安全问题呢？

根据刚才的两个结论，显然例 1 是没有问题的，因为每个 thread 对象都有一份 test 的 copy，因此访问任意成员函数都是线程安全的。 例 2 是有数据竞争存在的，因为所有 thread 都共享了同一个 test 的引用，根据刚才的结论 2，对于同一个 std::shared_ptr 对象，多线程访问 non-const 的函数是非线程安全的。
这个的 swap 改为 reset 也一样是非线程安全的，但如果改为 get () 就是线程安全的。

这里我们打开 Thread Sanitizer 编译例 2（clang 下是 -fsanitize=thread 参数），运行就会 crash 并告诉我们出现数据竞争的地方。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

==================
WARNING: ThreadSanitizer: data race (pid=11868)
  Read of size 8 at 0x00016ba5f110 by thread T2:
    #0 std::__1::enable_if<(is_move_constructible<SomeType*>::value) && (is_move_assignable<SomeType*>::value), void>::type std::__1::swap<SomeType*>(SomeType*&, SomeType*&) swap.h:38 (Untitled 4:arm64+0x1000061a8)
    #1 std::__1::shared_ptr<SomeType>::swap(std::__1::shared_ptr<SomeType>&) shared_ptr.h:1045 (Untitled 4:arm64+0x100006140)
    #2 main::$_0::operator()() Untitled 4.cpp:22 (Untitled 4:arm64+0x1000060d4)
    #3 decltype(static_cast<main::$_0>(fp)()) std::__1::__invoke<main::$_0>(main::$_0&&) type_traits:3918 (Untitled 4:arm64+0x100005fc8)
    #4 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0>&, std::__1::__tuple_indices<>) thread:287 (Untitled 4:arm64+0x100005ec4)
    #5 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0> >(void*) thread:298 (Untitled 4:arm64+0x100004f90)

  Previous write of size 8 at 0x00016ba5f110 by thread T1:
    #0 std::__1::enable_if<(is_move_constructible<SomeType*>::value) && (is_move_assignable<SomeType*>::value), void>::type std::__1::swap<SomeType*>(SomeType*&, SomeType*&) swap.h:39 (Untitled 4:arm64+0x1000061f0)
    #1 std::__1::shared_ptr<SomeType>::swap(std::__1::shared_ptr<SomeType>&) shared_ptr.h:1045 (Untitled 4:arm64+0x100006140)
    #2 main::$_0::operator()() Untitled 4.cpp:22 (Untitled 4:arm64+0x1000060d4)
    #3 decltype(static_cast<main::$_0>(fp)()) std::__1::__invoke<main::$_0>(main::$_0&&) type_traits:3918 (Untitled 4:arm64+0x100005fc8)
    #4 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0>&, std::__1::__tuple_indices<>) thread:287 (Untitled 4:arm64+0x100005ec4)
    #5 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, main::$_0> >(void*) thread:298 (Untitled 4:arm64+0x100004f90)
...

SUMMARY: ThreadSanitizer: data race swap.h:38 in std::__1::enable_if<(is_move_constructible<SomeType*>::value) && (is_move_assignable<SomeType*>::value), void>::type std::__1::swap<SomeType*>(SomeType*&, SomeType*&)

...

ThreadSanitizer: reported 4 warnings
Terminated due to signal: ABORT TRAP (6)

从错误信息中可以清晰地看到出现的数据竞争，在 22 行，也就是调用 swap () 的行。
如果确实需要在多线程环境下对同一 std::shared_ptr 实例做 swap () 操作，可以调用 atomic 对 std::shared_ptr 的重载函数，如：

1
2
3

template< class T >
std::shared_ptr<T> atomic_exchange( std::shared_ptr<T>* p,
                                    std::shared_ptr<T> r);

通过 weak_ptr 来避免循环引用

来看一个比较典型的 delegate/observer 的场景：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

#include <iostream>
#include <memory>

class DataFetcher {
public:
class Delegate {
public:
~Delegate() = default;
virtual void OnDataReady(void* any_data) = 0;
};

DataFetcher(std::weak_ptr<Delegate> delegate) : delegate_(delegate) {}

void FetchData() {
// ... fetch data from somewhere asynchronously
// and call back
auto delegate = delegate_.lock();
delegate->OnDataReady(nullptr);
}
private:
std::weak_ptr<Delegate> delegate_;
};

class DataManager : public DataFetcher::Delegate,
  public std::enable_shared_from_this<DataManager> {
public:
DataManager() {}

void FetchData() {
if (!data_fetcher_) {
data_fetcher_ = std::make_shared<DataFetcher>(shared_from_this());
}
std::cout << "Will fetch data with data_fetcher_" << std::endl;
data_fetcher_->FetchData();
}
void OnDataReady(void* any_data) override {
std::cout << "Got Data!" << std::endl;
}

private:
std::shared_ptr<DataFetcher> data_fetcher_;
};


int main(int argc, char *argv[]) {
auto manager = std::make_shared<DataManager>();
manager->FetchData();
}

这里例子里， DataManager 通过 std::shared_ptr<DataFetcher> data_fetcher_ 强持有 DataFetcher，DataFetch 通过 std::weak_ptr<Delegate> delegate_ 弱持有 DataManager。如果这里是 使用 std::shared_ptr<Delegate> delegate_ 强持有 DataManager 的话，那么 DataManager 和 DataFetch 将会造成循环引用，都得不到释放，造成内存泄漏。

可以看到，在构造 DataFetch 的时候， 我们使用了 shared_from_this() 作为参数：
data_fetcher_ = std::make_shared<DataFetcher>(shared_from_this());
它是 std::enable_shared_from_this<T> 类的一个方法。因为我们继承了 std::enable_shared_from_thi<T>，因此就可以拿到这个方法，它返回的是一个当前指针的 std::shared_ptr<T>.

那么它是怎么实现的呢？ 查看文档， 有如下描述：

A common implementation for enable_shared_from_this is to hold a weak reference (such as std::weak_ptr) to this. The constructors of std::shared_ptr detect the presence of an unambiguous and accessible (ie. public inheritance is mandatory) (since C++17) enable_shared_from_this base and assign the newly created std::shared_ptr to the internally stored weak reference if not already owned by a live std::shared_ptr (since C++17).

意思就是说，内部会持有一个 weak_ptt<T> wp, shared_from_this() 内部检查是否实现了 enable_shared_from_this 基类，如果实现了，就会基于 wp 创建一个 shared_ptr 返回出来。这样看起来挺巧妙。那么这个 weakptr 的指针是什么时候创建的呢？

enable_shared_from_this 源码实现

我们来扒一扒源码，先来看一下 enable_shared_from_this 模版类的实现，代码虽然不多，但是为了简单清晰，我把涉及不到的方法给移除掉了：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

template<class _Tp>
class _LIBCPP_TEMPLATE_VIS enable_shared_from_this
{
    // private 的 weak_ptr 指针：
    mutable weak_ptr<_Tp> __weak_this_;
public:
    _LIBCPP_INLINE_VISIBILITY
    shared_ptr<_Tp> shared_from_this()
        {return shared_ptr<_Tp>(__weak_this_);}

#if _LIBCPP_STD_VER > 14
    _LIBCPP_INLINE_VISIBILITY
    weak_ptr<_Tp> weak_from_this() _NOEXCEPT
       { return __weak_this_; }
#endif // _LIBCPP_STD_VER > 14

    template <class _Up> friend class shared_ptr;
};

有这么几点需要注意的：

1. 内部持有了 private 的 weak_ptr 指针 __weak_this_: mutable weak_ptr<_Tp> __weak_this_
2. shared_from_this() 直接返回的是 shared_ptr<_Tp>(__weak_this_)， 并不是 __weak_this_.lock()， 原因是前者如果 __weak_this_ 如果为空，将会抛出异常，后者会返回一个存储 nullptr 的 std::shared_ptr 对象。
3. C++ 14 之后，有 weak_from_this() 方法直接返回 __weak_this_
4. 把 class shared_ptr 设置为友元类，也就是说 shared_ptr 可以访问 enable_shared_from_this 的私有属性 __weak_this_

但是看不到什么时候给 __weak_this_ 初始化的。

shared_ptr 的部分源码

我们再拿出来 shared_ptr 源码来看下，shared_ptr 的源码较多，这里同样去掉一些不影响理解的逻辑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

template<class _Tp>
class shared_ptr
{
public:
    explicit shared_ptr(_Yp* __p) : __ptr_(__p) {
        unique_ptr<_Yp> __hold(__p);
        typedef typename __shared_ptr_default_allocator<_Yp>::type _AllocT;
        typedef __shared_ptr_pointer<_Yp*, __shared_ptr_default_delete<_Tp, _Yp>, _AllocT > _CntrlBlk;
        // 创建  Control Block
        __cntrl_ = new _CntrlBlk(__p, __shared_ptr_default_delete<_Tp, _Yp>(), _AllocT());
        __hold.release();

        // 注意这里，在创建 shared_ptr 的时候，会调用 __enable_weak_this 这样一个方法：
        __enable_weak_this(__p, __p);
    }

private:
    // __enable_weak_this 主实现：
    template <class _Yp, class _OrigPtr>
        typename enable_if<is_convertible<_OrigPtr*,
                                          const enable_shared_from_this<_Yp>*
        >::value,
            void>::type
        __enable_weak_this(const enable_shared_from_this<_Yp>* __e,
                           _OrigPtr* __ptr) _NOEXCEPT
        {
            typedef typename remove_cv<_Yp>::type _RawYp;
            if (__e && __e->__weak_this_.expired())
            {
                __e->__weak_this_ = shared_ptr<_RawYp>(*this,
                    const_cast<_RawYp*>(static_cast<const _Yp*>(__ptr)));
            }
        }

     // __enable_weak_this 的兜底实现：
     void __enable_weak_this(...) _NOEXCEPT {}

};

我们可以注意到在 shared_ptr 的构造函数里，会调用 __enable_weak_this() 这样一个方法，有两个参数，把包装的裸指针 __p 传入进去

__enable_weak_this 函数主实现使用了模版源编程 Template meta programming，不熟悉的话，可能乍一看有点蒙，这个稍后再说，先看函数体：

1
2
3
4
5
6
7
8
9
10
11
12
13

__enable_weak_this(const enable_shared_from_this<_Yp>* __e,
                    _OrigPtr* __ptr) _NOEXCEPT
{
    typedef typename remove_cv<_Yp>::type _RawYp;
    // 检查 __e->__weak_this_ 是否为空，expired() 返回 true 表示内部对象为空
    // 如果为空的话，则通过this 指针和 ptr 构造出来一个 shared_ptr, 并存入 __weak_this_ 中。
    if (__e && __e->__weak_this_.expired())
    {
        __e->__weak_this_ = shared_ptr<_RawYp>(*this,
            const_cast<_RawYp*>(static_cast<const _Yp*>(__ptr)));
    }
}

到这里我们搞清楚了，enable_shared_from_this 里的 __weak_this_ 是谁创建的，以及在什么时机创建的：

Answer: 在创建 shared_ptr<T> 的时候 (T 继承自 enable_shared_from_this<T>), 初始化了 enable_shared_from_this<T> 里的 __weak_this_ 指针。

Note:
如果仔细看的话，发现构造 shared_ptr 的时候有点奇怪，第一个参数是 shared_ptr<T> 类型，第二个是 __ptr 也就是当前 shared_ptr 对象管理的裸指针。

1	shared_ptr<_RawYp>(*this, const_cast<_RawYp*>(static_cast<const _Yp*>(__ptr)))

这个调用的是 std::shared_ptr 的别名构造函数（The aliasing constructor），意思是说，共享 r 参数的引用计数， 但是 .get() 返回的是 ptr 指针。

1 2	template< class Y > shared_ptr( const shared_ptr<Y>& r, element_type* ptr ) noexcept; // (8)

现在就剩下一个疑惑了，shared_ptr 怎么知道一个类型有没有继承自 enable_shared_from_this 呢？
这个就需要我们回过头来看 __enable_weak_this 的返回值类型，也就是下面这一坨：

1
2
3

typename enable_if<
            is_convertible<_OrigPtr*, const enable_shared_from_this<_Yp>*>::value,
            void>::type

对，这一坨最终会在编译期塌缩成一个类型，最终返回 void 或者空。当返回 void 时，__enable_weak_this 函数签名就是

1
2

void __enable_weak_this(const enable_shared_from_this<_Yp>* __e,
                    _OrigPtr* __ptr)

当塌缩成空时，__enable_weak_this 函数签名就是

1
2

__enable_weak_this(const enable_shared_from_this<_Yp>* __e,
                    _OrigPtr* __ptr)

显然这是一个不合法的签名，因此编译期发现整个不合法，就不生成这个函数了。
这个就是模板元编程的特点，编译器生成模版函数和我们手写函数的逻辑完全不同，我们手写的函数不合法，编译器就会报错，但是如果编译器生成出来的发现不合法，编译器就会不生成这个函数。
这个就是所谓的 SFINAE (Substitue Failure Is Not An Error) ，翻译过来就是：（模版）替换失败不是一个错误。

现在有两个问题：

1. 什么条件下返回 void 以及 空 呢？
2. 如果不生成 __enable_weak_this 函数， 那构造里调用的函数，是调的哪个呢？

对于第二个问题，比较简单，上面我们发现有个兜底的 __enable_weak_this 重载函数，调用的就是这个了，内部实现是空的，也就是什么也不做。

1
2
3

// __enable_weak_this 的兜底实现：
void __enable_weak_this(...) _NOEXCEPT {}

对于第一个问题，就是 enable_if 起的作用：
enable_if<bool 值， 类型T>::type 的意思是说，如果 bool 值为 true，enable_if 返回的就是第二个模版参数 类型T, 如果为 false，返回空（不是 void，而是什么也没有）
那么看下：

1

enable_if<is_convertible<_OrigPtr*, const enable_shared_from_this<_Yp>*>::value, void>::type

意思就是说，如果 is_convertible<_OrigPtr*, const enable_shared_from_this<_Yp>*>::value 返回 true 的话，也就是说我们的裸指针可以转换为 enable_shared_from_this<_Yp>*>::value, 其实也就是说，我们的裸指针类型是继承自 enable_shared_from_this<_Yp> 的。

所以这句话的意思就是说，如果传入的裸指针类型是继承自 enable_shared_from_this 的，那么 返回 void 类型，否则返回空，让 __enable_weak_this 函数替换失败，导致内部无法创建 __weak_this_ 指针，也就没办法通过 shared_from_this() 函数拿到当前 this 指针对应的 shared_ptr.

避免在构造函数里调用 shared_from_this ()

来看下面这个场景，在构造里注册 Observer，然后为了避免循环引用，这里我们传入一个 weak_ptr，看起来非常合理，你能看出来有什么问题吗？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class DataManager : public DataFetcher::Delegate,
    public std::enable_shared_from_this<DataManager> {
public:
DataManager(std::shared_ptr<SomeSubject> some_subject) : some_subject_(std::move(some_subject)) {
        //...
RegisterObserver();
}

void RegisterObserver() {
auto weak_self = std::weak_ptr<DataManager>(shared_from_this());
some_subject_->AddObserver(weak_self);
}

    void FetchData() {
}


private:
    std::shared_ptr<SomeSubject> some_subject_;
    //....
}

int main(int argc, char *argv[]) {
auto manager = std::make_shared<DataManager>();
manager->FetchData();
}

结果就是马上 crash 掉，如果对内部原理不清楚的话，很难一下子找到根本原因.

1
2

libc++abi: terminating with uncaught exception of type std::__1::bad_weak_ptr: bad_weak_ptr
Terminated due to signal: ABORT TRAP (6)

根据上面我们看 shared_from_this () 的源码实现会发现它是通过 _weak_this 来构造出来的，不管是 make_shared 内部会先调用 new DataManager 创建指针，然后再创建 _weak_this_，因此在 DataManager 构造函数被调用时，__weak_this 还没有创建出来，因此会报 bad_weak_ptr 的错误。

1
2

shared_ptr<_Tp> shared_from_this()
        {return shared_ptr<_Tp>(__weak_this_);}

以上。

1. 我们在聊函数调用的时候在聊什么？

至少我们应该把函数调用的几个问题搞清楚:

Function Call Convention 其实就是回答这些问题的，接下里我们一一找到答案.

1.1. 函数调用本质是什么？

汇编层是没有函数的概念的，我们需要把函数映射到汇编层来，这样我们就知道了它的本质。其实执行一个程序，在汇编层来看就是不断的执行 CPU 指令，都执行完了，进程就结束了。从第一篇的例子其实可以看出，一个函数就是一个 label, 等于代码段中该函数第一条指令的位置。其实本质上函数调用，就是程序从代码段的某一条指令，跳转到另外一个地址上的指令去执行。稍微复杂点的 C 程序都不是从头执行到尾就结束了，会有条件判断，函数调用。函数调用和普通跳转不同的地方在于要处理传参、返回、以及寄存器的 backup 和恢复.

AArch64 提供给我们了一个 bl (branch with link) 指令，用来执行指定的函数。第一篇里，我们介绍了 cmp 以及 b.le/b.ge 等，‘b’ 在这两处都是 branch 跳转的意思.

只不过 bl 是跳转的函数地址上，bl 内部实现是这样的:

1.2. AArch64 Call Convention 约定

ps: 还有一种间接传递返回值的方式，该方式会使用 XR (X8) 进行间接的返回，后文会介绍这种 case.

2. 看一个简单函数调用例子

1
2
3
4
5
6
7
8

long add(long x, long y) {
    return x + y;
}

int main() {
    long z = add(1, 2);
    return 0;
}

对应的 AArch64 的汇编代码:
ps: 这里为了方便阅读，我把 add 函数调整到了 main 的后面，下同

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

main:                                   // @main
  // 1. 分配 48 字节的栈空间, 使用情况见 step 11
  sub     sp, sp, #48                     // =48

  // 2. stp 和 str 类似, 区别是 stp 一次保存多个
  // 这里等于把 x29/FP => [sp + 32], x30/LR => [sp + 40]
  stp     x29, x30, [sp, #32]             // 16-byte Folded Spill

  // 3. x29 = sp + 32
  add     x29, sp, #32                    // =32

  // 4. w8 = 0, 然后存入后面能用到
  mov     w8, wzr

  // 5. x29-4 = sp+32-4 = sp + 28
  stur    wzr, [x29, #-4]

  // 6. 把字面量 1 和 2 放入 X0, X1, 作为入参传给 add
  mov     x0, #1
  mov     x1, #2

  // 7. 前面把 w8 置为 0, 这里相当于在 sp+12 位置保存了一个 0
  str     w8, [sp, #12]                   // 4-byte Folded Spill

  // 8. 函数调用
  bl      add(long, long)

  // 9. 把 X0 也就是返回值, 放入 sp + 16 中
  str     x0, [sp, #16]

  // 10. 因为 main 的返回值是 int, 4 字节, 所以用的是 w0, sp+12 前面我们知道保存的是 0
  // 所以这里相当于把 0 放入了 w0, 作为 main 函数的返回值
  ldr     w0, [sp, #12]                   // 4-byte Folded Reload

  // 11. 回顾一下分配的 48 字节栈空间的使用情况
  | sp + 40  |  LR (8 bytes)
  | sp + 32  |  FP (8 bytes)
  | sp + 24  |  0  (8 bytes, 低四位(sp + 28) 存放 0)
  | sp + 16  |  X0 (8 bytes)
  | sp + 8   |  0  (8 bytes, 低四位(sp + 28) 存放 0)
  | sp       |     (8 bytes, 为了16对齐, 多分配出来的)

  // 和 step2 操作相反, 恢复 X29, X30, 也就是 FP 和 LR 寄存器
  // 类似 ldr, ldp load 多个: X29 <= [sp + 32], X30 <= [sp + 40]
  ldp     x29, x30, [sp, #32]             // 16-byte Folded Reload

  // 释放栈空间
  add     sp, sp, #48                     // =48
  ret

add(long, long):                               // @add(long, long)
  // add 函数有两个 long 参数, 会占用栈空间, 分配 16 字节
  sub     sp, sp, #16                     // =16

  // X0 是第一个参数 x, 保存到 sp + 8
  str     x0, [sp, #8]
  // X1 是第二个参数 y, 保存到 sp 中
  str     x1, [sp]

  // 取出 x 和 y
  ldr     x8, [sp, #8]
  ldr     x9, [sp]

  // 相加, 把和放入 X0 中, 也是约定的返回值存放位置
  add     x0, x8, x9

  // 释放栈空间
  add     sp, sp, #16                     // =16
  // 返回
  ret

3. 参数超过 8 个参数，通过栈空间传递参数的例子

test 函数共有 10 个参数，为了保持简单，这里都使用 long 类型的.

1
2
3
4
5
6
7
8
9

long test(long n1, long n2, long n3, long n4, long n5,
          long n6, long n7, long n8, long n9, long n10) {
    return n1 + n2;
}

int main() {
    long z = test(1, 2, 3, 4, 5, 6, 7, 8, 9, 10);
    return 0;
}

我们先看一下函数调用的时候，栈的分配，下面是对应的 AArch64 的汇编代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125

main:                                   // @main

  // 1. 这部分和上面例子非常类似, 不赘述了
  sub     sp, sp, #64                     // =64
  stp     x29, x30, [sp, #48]             // 16-byte Folded Spill
  add     x29, sp, #48                    // =48
  mov     w8, wzr
  stur    wzr, [x29, #-4]

  // 2. 前 8 个参数通过通用寄存器 X0-X8 传递
  mov     x0, #1
  mov     x1, #2
  mov     x2, #3
  mov     x3, #4
  mov     x4, #5
  mov     x5, #6
  mov     x6, #7
  mov     x7, #8

  // 3. 这三条指令相当于把第 9 个参数 #9 放入 [sp], 也就是栈顶的位置
  mov     x9, sp
  mov     x10, #9
  str     x10, [x9]

  // 4. 把第 10 个参数 #10 放到 [sp + 8], 也即是栈顶的下一个位置
  mov     x10, #10
  str     x10, [x9, #8]

  // 5. 此时栈的情况是这样的:
  | sp + 40  |
  | sp + 32  |
  | sp + 24  |
  | sp + 16  |  其他值
  | sp + 8   |  #10, 第 10 个参数
  | sp       |  #9, 第 9 个参数

  stur    w8, [x29, #-20]                 // 4-byte Folded Spill

  // 6. 执行函数调用
  bl      test(long, long, long, long, long, long, long, long, long, long)

  // 7. 也和前面例子非常类似, 不赘述
  stur    x0, [x29, #-16]
  ldur    w0, [x29, #-20]                 // 4-byte Folded Reload
  ldp     x29, x30, [sp, #48]             // 16-byte Folded Reload
  add     sp, sp, #64                     // =64
  ret

test(long, long, long, long, long, long, long, long, long, long): // @test(long, long, long, long, long, long, long, long, long, long)
  // 10个参数, 分配 80 字节的栈空间, 也是 16 的倍数
  sub     sp, sp, #80                     // =80

  // 结合上面第5步, 我们可以知道当前栈是这样的:
  // 前面 sp = sp - 80, 所以这里 main 函数栈相当于离栈顶 sp 又远了80, 需要 + 80
  ----main func----
  | sp + 40 + 80  |
  | sp + 32 + 80  |
  | sp + 24 + 80  |
  | sp + 16 + 80  |  其他值
  | sp + 8  + 80  |  #10, 第 10 个参数
  | sp      + 80  |  #9, 第 9 个参数
  ----test func----
  | sp +      72  |
  | sp +      64  |
  | sp +      56  |
  | sp +      48  |
  | sp +      40  |
  | sp +      32  |
  | sp +      24  |
  | sp +      16  |
  | sp +      8   |
  | sp            |
  -----------------

  // 这个初看有些奇怪, 一共分配了 80 自己的空间, 那这里的 sp + 80, 岂不是访问出界了啊?
  // 实际上是特意的, 根据前图, sp + 80 相当于访问到了 #9 所在的位置, 所以 x8 = #9
  // 同理 x9 实际访问到了 [sp, #88], 也就是 #10 所在的位置, 所以 x9 = #10
  // 这样就拿到了最后两个参数
  ldr     x8, [sp, #80]
  ldr     x9, [sp, #88]

  // 前 8 个参数, 逐个压入到栈中. 空余了 sp 和 sp + 8
  str     x0, [sp, #72]
  str     x1, [sp, #64]
  str     x2, [sp, #56]
  str     x3, [sp, #48]
  str     x4, [sp, #40]
  str     x5, [sp, #32]
  str     x6, [sp, #24]
  str     x7, [sp, #16]

  // 再把从前面函数栈中拿到的第 9、10 个参数入栈
  str     x8, [sp, #8]
  str     x9, [sp]

  // 此时 函数栈中的值是这样的:
  ----main func----
  | sp + 40 + 80  |
  | sp + 32 + 80  |
  | sp + 24 + 80  |
  | sp + 16 + 80  |
  | sp + 8  + 80  |  #10, 第 10 个参数
  | sp      + 80  |  #9, 第 9 个参数
  ----test func----
  | sp +      72  |  #1
  | sp +      64  |  #2
  | sp +      56  |  #3
  | sp +      48  |  #4
  | sp +      40  |  #5
  | sp +      32  |  #6
  | sp +      24  |  #7
  | sp +      16  |  #8
  | sp +      8   |  #9
  | sp            |  #10
  -----------------

  // 拿出 #1 和 #2, 相加的结果 3 放入 X0 作为返回值
  ldr     x8, [sp, #72]
  ldr     x9, [sp, #64]
  add     x0, x8, x9

  // 释放栈空间
  add     sp, sp, #80                     // =80
  ret

4. 总结一下函数调用的通用逻辑

正式开始之前，我们先来了解一下什么是 ARM, 以及对应的一些概念.

Wikipedia 上是这么介绍 ARM 的:

ARM 是 高级 - RISC (精简指令集)- 机器 的缩写，是精简指令集架构的家族。同时 Arm Ltd. 也是开发和设计、授权这项技术的公司名称.

1.1. 有哪些指令集架构呢？(TRDR, 可跳过)

目前用的比较多的架构是 ARMv7 和 ARMv8, 这两个名字各自都是一个系列.

在 ARMv7 以及之前都是最多支持 32 位架构 (更早还有 16 位，甚至更低), 那么 32 位架构对应的 ISA 也就是指令集称为 A32. 32 位下指令的地址空间最大只有 4GB, 苹果系列的代表是 iPhone 4 使用的 A4 芯片，以及 iPhone 4s 使用的 A5 芯片.

2011 年面世的 ARMv8-A 架构增加了对 64 位地址空间的支持，对应的 ISA 称为 A64. 这里用的词是 “增加”, 也就意味着在支持 32 位的基础上增加了对 64 位的支持。所以也可以看出来所谓的 32/64 位指的就是可寻址的最大地址空间。苹果系列从 iPhone 5s 开始的 A7 芯片一直到 A15, 以及 Apple M1 系列开始都是基于 ARMv8.x-A 规范的.

那我们见到的 AArch64 是什么呢？其实它和 AArch32 被称为 “执行状态” (execution state), 那么我们可以说 ARMv8-A 同时支持 AArch32 和 AArch64 两种状态，在 AArch64 状态下，运行的是 A64 指令集.

这里要注意 ARMv7/ARMv8-A、AArch32/AArch64 以及 A32/A64 在概念上的的区别，但很多时候，描述的范围都挺笼统的，有些也是可以互相指代的，大家知道就好.

上面说到指令集，指令集是做什么用的呢？我们为什么要了解这些？

指令集本质上定义了 CPU 提供的 “接口”, 软件通过这些 “接口” 调用 CPU 硬件的能力来实现编程。编译器在这里起到很关键的角色，它把上层代码根据对应的架构，编译为由该架构支持的指令集对应的二进制代码，最终运行在 CPU 上.

对 C 系语言来说，我们说的跨平台，其实就是通过同一份源码在编译时，根据不同 target 架构指令集，生成不同的二进制文件来实现的.

1.2. 本系列的目的：为什么要了解 ARM 汇编指令？

对我们来说熟悉 ARM 汇编指令，我们就能知道我们平常写的代码背后的本质，以及背后的原理，从而写出更高效，更可靠的代码。主要是编译器内部对 C/C++ 概念的实现原理.

这个系列也是本着这个初衷展开，适合对 AArch64 不熟，或者熟悉 x86/64 的汇编，想了解 AArch64 的同学。而且对 C/C++ 语法或者特性背后实现感兴趣的同学.

我其实也是最近才开始捡起来，之前学习的 x86 汇编早就还给老师了。相当于一边学习一边总结吧。好处是我大概知道刚开始可能会遇到哪些问题，在此基础上，尽可能的减少阅读门槛，这不是一个手册，而是一个循序渐进，目的性很强的一个系列.

因为目前 Apple M1 芯片就是基于 ARMv8.x-A 的，我们为了方便试验，接下来都选择使用基于 ARMv8-A A64 指令集来做解释.

2. 认识 A64 指令集下的常用指令

ARM 使用的是精简指令集 (RISC, Reduced Instruction Set Computer), 相对的就是 x86/64 的复杂指令集 (CISC, Complex Instruction Set Computer).

2.1. RISC 的一些特点:

1. 精简指令集提供的指令更简单，更基础一些，也就是说，和 x86/64 相比，同样的代码，生成的指令会多一些.
2. 内存访问和计算是完全分离的. RISC 使用 load 读取内存数据到通用寄存器中，计算完之后通过 store 保存到内存中

2.2. ARM64 的约定:

1. 每个指令都是 32 位宽
2. ARM64 有 31 个通用寄存器: X0-X30, 每个都是 64 位。如下图 1, 低 32 位可以通过 W0-W30 来访问。当写入 Wy 时，Xy 的高 32 位会被置 0, 比如 ADD W0, W1, W2
3. 提供 32 个 128 位的独立的寄存器，用于浮点数以及向量操作，如下图 2, Qx 表示 128 位，Dx 表示 64 位，以此类推.
   1. 执行 32 位浮点数计算: FADD S0, S1, S2.
   2. 也可以直接使用 Vx 的方式，此时表示的就是向量操作，如
      FADD V0.2D, V1.2D, V2.2D
4. 其他的寄存器:
   1. ZXR/WZR 不可写，始终为 0
   2. SP, Stack Pointer, 栈指针寄存器，load 和 store 的基址，指向栈顶
   3. X29 用来表示 FP Frame Pointer, 方法调用的时候，指向栈基址，用于方法调用后恢复栈.
   4. X30 被用作 LR Link Register, 也可以通过 LR 来使用。在方法调用前，保存返回地址.
   5. PC, Program Counter 寄存器在 A64 里不是通用寄存器，数据处理中不可用。等价写法是 ADR Xd, ., 点表示当前行，ADR 取地址，相当于取当前行的地址，也就相当于 PC 寄存器的值
   6. macOS 中 X18 被禁用

(图 1)

(图 2)

3. 一些常用基础指令的用法

指令的构成通常是这样的:

Operation Destination, Op1[, Op2 ..]

• Operation 描述指令的作用，比如 ADD 表示加，AND 进行逻辑与操作
• Destination 总是为寄存器，存放操作的结果
• Op1, 指令的第一个输入参数，总是为寄存器
• Op2, 指令的第二个输入参数，可以是一个寄存器，或者是常量值

不一定所有的制定规则都是这样的，为了减少理解的成本，我们先介绍几个简单却又必须的指令，其他的指令会在后面用到时再做介绍.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

// X1 存储了一个地址, 把 X1 寄存器里的地址对应的值, load 到 X0 寄存器中. 相当于 X0 = *X1
ldr X0, [X1]

// X0 = X0 + 1
ADD X0, X0, #1

// 再把 X0 寄存器的值, 保存到 X1 地址对应的内存中, 相当于 *X1 = X0
str X0, [X1]

// 访问内存可以加一个 offset, 相当于把 X0 保存到 新地址 = (地址 X1 + 4) 对应的内存中. lrd 也同理.
str X0, [X1, #4]

// ldp(load pair registers) 和 ldr 类似, 一次 load 两个
ldp X0, X1, [sp, #num]

// 同理, stp(store pair registers) 保存两个 register 到内存
stp X0, X1, [sp #num]

// 用 mov 移动一个寄存器或者立即数到目的寄存器中
mov X0, X1
mov X0, #0x01

通过 label 在 code segment 里定义 local data:
msg: ascii "Hello"  // 定义字符串
number: word 0x12345678  // 定义一个 4 字节的数据. byte, word(4bytes), quad(8bytes)

// ADR 取地址符, 把 Hello 字符串的地址放入 X1 寄存器:
adr X1, msg

// 算数运算, 加减乘除: add, sub, mul, sdiv/udiv (signed/unsigned div):
add x0, x1, x2

// 逻辑运算, lsl/lsr logical shift left/right.
lsl X0, #16  // 把 X0 左移 16 bits
lsr X0, #16

// 控制流, 通过 b 指令跳转

// 直接跳转到 .LBB0_6
b       .LBB0_6

// less or equal
b.le    .LBB0_2

// greater or equal
b.ge    .LBB0_4

// not equal
b.ne    .LBB0_4

//TODO(xueshi)

4. 进程内存布局

熟悉程序加载到内存之后的布局，对编写 / 阅读汇编代码至关重要，这里我们熟悉一下经典的内存布局，主要目的是方面理解后面的汇编代码。这里不展开西说，更详细的大家可以自行查询资料.

下面讨论的地址都是虚拟地址，虚拟地址最终会被操作系统映射到真实的物理地址中。所以我们也可以知道在 32 bit 指令集下，虽然寻址空间最大 4GB, 因为用了虚拟内存，实际上每个执行的进程都有 4GB 的寻址空间 (一般是 1G 内核空间，3G 用户空间), 并不是共享的.

当一个可执行程序被 load 到一个进程空间之后，内存布局如下。按段 (Segment) 来划分的，逐个来介绍.

1. 最下面的是代码段，保存着二进制的代码，主要是各种函数，拥有只读和执行的权限。这个段的代码可以被执行，但是不可写入.
2. 数据段，主要保存常量值或全局静态值，拥有只读权限，也是不可写入的.
3. 堆，堆空间主要是用来动态分配内存的，我们用的 malloc, new 等申请的内存空间都会在这个区域，权限会读写。分配的虚拟内存地址由小增大，所以是向上增长的.
4. 栈空间，栈空间主要是保存临时变量以及方法调用的参数。栈空间分配的方向是从大到小的，和 Heap 分配的方向是相对的。这么设计一方面是可以和 Heap 共用中间的待分配内存，另外一个原因是，每个方法里的临时变量所占用的内存在编译期其实就已经确定了，执行方法开始时一次性的分配所需的栈空间，执行结束一次性释放掉。其实堆空间和栈空间并没有物理上的差别，只是逻辑上定义如此.
5. 内核空间，内核空间和栈空间一般还会有间隔，这里没画出来

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

|--------------|
| Kernal Space |
|--------------| 高地址
|              | 栈地址 从高到低 向⬇增长
|     Stack    |
|              |
|--------------|
|              |
|   待分配内存   |
|              |
|--------------|
|              | 堆地址 从低到高 向⬆增长
|     Heap     |
|              |
|--------------|
| Data Segment |
|--------------|
| Code Segment |
|--------------| 低地址

5. 栈操作

栈操作是看懂汇编代码必备的，因为每个函数几乎都要开辟自己的一片栈空间，我们也称为 stack frame, 也就是我们常见到的 “栈帧”, 随着函数调用创建，函数结束调用释放销毁.

Stack frame 主要有两个基础用途，一个是存储临时变量，再者是函数调用和传参。后者会在后面的文章的讲述，这里我们主要看一下在没有函数调用的情况下栈空间的使用.

随便实现一个 test 函数，在 main 函数里调用它:

1
2
3
4
5
6
7
8
9
10
11

long test() {
    long x = 5;
    long y = 3;
    long z = 4;
    return x + y;
}

int main() {
    test();
    return 0;
}

如图 3, 在 GodBolt 里使用 armv8-a clang 11.0.1 编译器 生成汇编代码 (这里省略 main 函数):

(图 3)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

test():  // @test()
    // 栈空间是从高地址往低地址分配空间的, 我们看到有 x y z 三个本地临时变量
    // 共 3*long = 24bytes, 也就是需要 24 字节的栈空间
    // 但是 arm64 有个约定, 分配栈空间的大小须为 16 字节的倍数, 所以这里需申请 32bytes

    // sp = stack pointer, 指向栈顶(也是栈空间里可用的最低地址)
    // 我们看到这里直接 通过 sp=sp-32 来开辟了 32 字节的空间
    // 而且 32 是立即数, 也就是编译器在编译期就已经确定了的.
    sub     sp, sp, #32   // =32

    // 申请之后可用的栈空间是这样的, sp 指向了栈顶:
    // | sp + 24|  8 bytes
    // | sp + 16|  8 bytes
    // | sp + 8 |  8 bytes
    // | sp     | 8 bytes

    // 对应 x=5, 不能直接把 5 放到内存, 需要寄存器中转一下, 先把 5 放入 x8 寄存器
    mov     x8, #5  // 立即数以#开头, 这里把5放到x8寄存器中
    // sp 既然是指针, 也就是地址, 所以支持
    // 1. 地址支持加减运算, 2: 存取(store/load) 数据都需要使用 [] 来找到地址所对应的值
    // 然后接上面, 把 x8 也就是 5, 放入了 sp + 24 对应的地址里
    str     x8, [sp, #24]

    mov     x8, #3  // 同上, 操作y
    str     x8, [sp, #16]

    mov     x8, #4  // 同上, 操作z
    str     x8, [sp, #8]

    操作完之后, 栈空间是这样的:
    // | sp + 24|  就是 x, 值为 5
    // | sp + 16|  就是 y, 值为 3
    // | sp + 8 |  就是 z, 值为 4
    // | sp     | 未使用

    // 可见这里入栈顺序和临时变量定义的顺序是一致的

    //  操作 x + y
    ldr     x8, [sp, #24] //把 x 读取到x8
    ldr     x9, [sp, #16] //把 y 读取到x9

    // 现在 x0 = x8+x9, 保存着相加的结果值 8
    add     x0, x8, x9

    // 释放分配的栈空间, 其实就是把 sp + 32, 相当于 sp 指针向上移动了 32 个字节
    // 那我们知道栈空间分配的方向是从高地址到低地址, 释放就是相反的方向也容易理解了.
    add     sp, sp, #32                     // =32

    // 默认返回 x0, 后文会介绍
    ret

main:   // @main
    ...省略

我们总结一下，其实也很简单，记住下面几个就够了:

6. REFs

1. ARM architecture family
2. iOS Support Matrix
3. Shellcode for macOS on M1 chips - Part 1: Quick overview of ARM64 assembly language
4. ARM 官方的文档 (没有链接)