struct 内存对齐

C/C++ 中 struct 的内存对齐

Share
struct 内存对齐
Photo by Brett Jordan / Unsplash

struct 的内存结构

在学习 Objective-C Blocks 的时候,有这样一段代码:

struct __main_block_impl_0 {
  struct __block_impl impl;
  struct __main_block_desc_0* Desc;
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
    impl.isa = &_NSConcreteStackBlock;
    impl.Flags = flags;
    impl.FuncPtr = fp;
    Desc = desc;
  }
};
static void __main_block_func_0(struct __main_block_impl_0 *__cself) {

        printf("Block\n");
    }

static struct __main_block_desc_0 {
  size_t reserved;
  size_t Block_size;
} __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0)};
int main(int argc, const char * argv[]) {
    void (*blk)(void) = ((void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA));
    ((void (*)(__block_impl *))((__block_impl *)blk)->FuncPtr)((__block_impl *)blk);
    return 0;
}

我对类似 (__block_impl *)blk 这样的类型转换很是不解,为啥能把一个 __main_block_impl_0 类型转成 __block_impl 类型呢?后来深入研究后才想起来,这原来是利用的 struct 的内存结构和内存对齐。

struct 是一种简单的数据结构,能够把各种不同类型的数据聚合在一起。

在 C/C++ 中,struct 的数据结构具有内存连续性的特点。这意味着 struct 中所有的成员在内存中存储的位置是连续的。但连续并不代表它们是紧挨着的。例如下面这个 struct,打印一下各个成员的内存地址:

struct S {
    short s;
    int i;
    double d;
};

int main() {
    S s = {};
    cout << &s << endl;
    cout << &s.s << endl;
    cout << &s.i << endl;
    cout << &s.d << endl;
    cout << sizeof(s) << endl;
}

// output:
// 0x16f9771c0
// 0x16f9771c0
// 0x16f9771c4
// 0x16f9771c8
// 16

struct 的起始地址和其第一个成员的地址一致,都是 0x16f9771c0 。第二个成员 i 为 int 类型,需要占用 4 个字节,地址相对于 struct 起始地址偏移了 4 个字节。第三个成员 d 是 double 类型,需要占用 8 个字节,地址相对于 struct 起始地址偏移了 8 个字节。而 d 是 struct 最后一个成员,地址偏移量 8 个字节加上本身占用了 8 个字节,加一起正好等于 struct 占用的全部内存大小。

struct 各成员的内存地址偏移是有一定规律的,这个规律称为内存对齐

为什么需要内存对齐

内存对齐是为了提高内存的访问速度,减少 CPU 访问内存的次数。CPU 访问内存时并不是一个字节一个字节地访问,而是以字长(word size)为单位访问。例如 32 位 CPU 的字长是 4 个字节,其访问内存的单位也是四个字节。

以上面的 struct S 为例,如果不进行内存对齐,而是让成员之间首尾紧挨在一起的话,那么其内存结构是这样的:

总共占用 2 + 4 + 8 = 14 个字节。在已知 struct 起始地址,也就是上图中位置为 0 的地址的情况下,CPU 想要访问成员 i 的话需要跨两个字长,也就是需要两次访问。访问结束后将两次访问的数据拼在一起才能得到成员 i 的完整数据。

但如果进行内存对齐的话,结构体的内存结构是这样的:

其中黑色块是为了内存对齐而偏移的字节,其中不存储成员数据。这时候访问成员 i 的话,就只需要一次访问就能够获取成员 i 的全部数据了。

因此进行内存对齐能够有效减少内存访问次数,提高性能。但这也是个典型的空间换时间的场景,因为中间有很多填充字节并没有存储真实数据。

内存对齐的规则

如果一个变量的内存地址正好位于它长度的整数倍,就被称作自然对齐

struct 内存对齐原则:

  • struct 的起始地址要能被其成员中最宽(占用字节数最多)的基本数据类型整除;
  • struct 的大小(size)也要能被其成员中最宽的基本类型整除;
  • struct 中每个成员的地址相对于 struct 起始地址的偏移必须是自然对齐的。

前面定义的 struct S 就符合这些规则。首先 short 类型的成员 s 的起始地址偏移量为 0,是第一个成员。第二个成员 i 是 int 类型,需要 4 个字节,因此自然对齐需要的偏移量是 4。最后一个成员 d 需要 8 个字节,偏移量为 8,恰好紧挨着成员 i 的尾巴,符合自然对齐。成员都自然对齐后,struct 所需总字节数为 16,能够被 8 整除。实例 s 的内存起始地址为 0x16f9771c0,转成十进制就是 6167163328,也能被 8 整除。

利用偏移量访问成员变量

struct Person
{
    int citizenship;
    int age;
};

int main() {
    int *age;
    int *city;
    auto temp = Person { 10, 11};
    auto person = &temp;
    city = (int *)person;
    size_t offset = offsetof(Person, age);
    age = (int *)((unsigned long)city + (unsigned long)offset);
//    age = city + offset / sizeof(int);
    cout << *city << endl;
    cout << *age << endl;
    cout << sizeof(Person) << endl;
    return 0;
}

// output:
// 10
// 11
// 8

上面代码中分别利用了 citizenship 和 age 的偏移量间接通过地址访问了 Person 的成员变量。

💡
注意指针的算数运算。pointer++ 并不代表将地址 pointer 加 1 个字节,而是加 sizeof(int) * 1 个字节。计算的时候可以将十六进制的地址转成 unsigned long 或者加偏移量的同时除以 sizeof(int)

Read more

在 AI 时代,做 iOS 逆向分析有哪些高效手段

在 AI 时代,做 iOS 逆向分析有哪些高效手段

AI 发展如此迅猛,传统的代码手艺活已经被 AI 取代了很大一部分。除了生成代码外,AI 在其他的研发流程也能提升很多效率,例如这次要说的 AI 逆向分析。 在手工时代,我们逆向分析一个 iOS app,通常是使用 Hopper 或者 IDA 等软件查看解密的 Mach-O,然后利用软件提供的能力加上人工去分析逻辑流程。这个过程还要求我们懂一些基础的汇编语法。有时候还要去猜测哪些类哪些方法是负责某个逻辑,靠试验去验证。 现在来到了大模型时代,AI 不仅能自己通过一些简单的工具去分析 ipa 和 Mach-O ,也能使用更准更稳的 MCP、Skill 工具来做深度的分析。 Hopper MCP Hopper 在新版本支持了 MCP Server。 把 framework、Mach-O 或者解密后的 IPA 直接丢给它,

By Gray
Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder(Github) 是一个无需逐模块启动注册、支持字符串、类型和函数调用的 Swift 编译期注册框架。 Cinder 是什么 在 iOS app 里借助 Mach-O 注册能力做一些二进制的插桩操作并不罕见。以往这些操作大都使用 objc runtime ,借助 __attribute__((used)) 和 __attribute__((section("name"))) 实现。在 Swift 上实现有一些难度,因为 Swift runtime 能力弱,以及早期的版本没有类似 objc 的 __attribute__ 能力。 * 在 Swift 5.10 版本,Apple 提供了 @_used 和

By Gray