本篇博客来认识一下linux下程序地址空间的概念

演示所用系统:CentOS 7.6

[TOC]

1.引入程序地址空间

之前学习C/C++的时候,多少应该都听过栈区/堆区/静态区/全局区的概念,还有一张很经典的演示图,大部分讲解这几个内存区域的图片都和下图类似

image-20221007151039950

但是有一个问题,这里的程序地址空间,是我们的物理内存上的东西吗?

并不是!

  • 程序/进程地址空间是操作系统上的概念,它和我们物理内存本身不是一个东西

1.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
30
31
32
33
34
35
36
37
38
39
40
#include<stdio.h>
#include<stdlib.h>

int un_global_val;//未初始化全局变量
int global_val=100;//已初始化全局变量
//main函数的参数
int main(int argc, char *argv[], char *env[])
{
printf("code addr : %p\n", main);
printf("init global addr : %p\n", &global_val);
printf("uninit global addr: %p\n", &un_global_val);
char *m1 = (char*)malloc(100);
char *m2 = (char*)malloc(100);
char *m3 = (char*)malloc(100);
char *m4 = (char*)malloc(100);
int a = 100;
static int s = 100;
printf("heap addr : %p\n", m1);
printf("heap addr : %p\n", m2);
printf("heap addr : %p\n", m3);
printf("heap addr : %p\n", m4);

printf("stack addr : %p\n", &m1);
printf("stack addr : %p\n", &m2);
printf("stack addr : %p\n", &m3);
printf("stack addr : %p\n", &m4);
printf("stack addr a : %p\n", &a);
printf("stack addr s : %p\n", &s);
printf("\n");
for(int i = 0; i < argc; i++)
{
printf("argv addr : %p\n", argv[i]);
}
printf("\n");
for(int i =0 ; env[i];i++)
{
printf("env addr : %p\n", env[i]);
}
return 0;
}

image-20221007151932639

通过上面的测试,可以看到其结果和文章最开始的那张图相同。这里解释一下向上/向下的含义

  • 向上增长:向地址增大的方向增长
  • 向下增长:向地址减小的方向增长

不过那个图片内部还少了一些东西,比如命令行参数和环境变量其实是存放在栈区之上的。补全之后的图片如下

image-20221007152623384

其中我们还可以发现,栈区和堆区之间有非常大的内存空隙

1
2
3
4
heap addr         : 0x1a140f0
heap addr : 0x1a14160
stack addr : 0x7ffe6671ec60
stack addr : 0x7ffe6671ec58

因为在C/C++中定义的变量都是在上保存的,栈向下增长,先定义的变量地址较高!

1
2
int a = 100;
static int s = 100;

关于函数中static修饰的变量,可以看到其地址空间属于全局静态区。虽然在函数中用static修饰是限制其只能在该函数内访问,但是该变量的声明周期是跟随整个程序的!

1
2
stack addr a      : 0x7ffe6671ec44
stack addr s : 0x601048

说了这么多,我们也没看看出来程序地址空间在哪儿啊?

1.2 fork感知地址空间的存在

下面可以用一个简单的fork代码来确认程序地址空间的存在!

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
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/types.h>

int main()
{
int test = 10;
int ret = fork();
if(ret == 0)
{
while(1)
{
printf("我是子进程%d,ppid:%d,test:%d,&test: %p\n\n",getpid(),getppid(),test,&test);
sleep(1);
}
}
else
{
while(1)
{
printf("我是父进程%d,ppid:%d,test:%d,&test: %p\n\n",getpid(),getppid(),test,&test);
sleep(1);
}
}
return 0;
}

依旧是最简单的一个fork代码,正常情况下,二者打印的结果应该是一样的!

image-20221007154111800

可如果我们在子进程中修改一下test呢?

image-20221007154330028

这时候就会发现一个离谱的现象:子进程和父进程打印的test值不一样,但是其地址却完全相同

如果我们在C/C++中使用的地址就是物理地址,是不可能出现这种情况的!怎么可能在物理内存的同一个地址访问出两个不同的结果呢?

就好比张三和李四在同一天的同一时间去了AA路30号这个地址,不可能会出现张三去了发现是超市,而李四去了发现是医院的情况

这便告诉我们了程序地址空间的存在,亦或者说,我们在编程中使用的地址都是虚拟地址

2.简述程序地址空间

每一个进程在启动的时候,都会让操作系统给其分配一个地址空间,这就是进程地址空间

  • 先描述再组织的理念,进程地址空间其实是操作系统内核的一个数据结构struct mm_struct
  • 之前提到过进程具有独立性,在多进程运行的时候,需要独享各种资源。而进程地址空间的作用,就是让进程认为自己是独占操作系统中的所有资源!

这个操作,其实就是操作系统给该进进程画了一个假的内存(虚拟地址)进程需要内存的时候,操作系统就会在页表里面画一个地址给他,再将该地址映射到物理内存上面

问题:一个分页存储管理系统中,地址长度为 32 位,其中页号占 8 位,则页表长度是?

解析:页号即页表项的序号,总共占8个二进制位,意味着页表项的个数就是2^8

image-20221007203947913

而当进程需要申请内存的时候,本质就是操作系统在mm_strcut中修改不同区域的end罢了!

在Linux源码中可以看到这玩意的存在,其中的struct vm_area_struct * mmap;就是一个我们的虚拟地址管理的内核

image-20221007203759071

这里就能看到虚拟地址空间的start和end了!

image-20221007203918107

2.1 程序地址空间和代码编译

程序地址空间不仅是操作系统需要考虑,我们用的编译器也会考虑这部分的内容

我们知道,C语言代码需要经过预处理-编译-链接-汇编这几个步骤

  • 程序编译出来,没有被加载的时候,程序内部有地址(如果没有地址,无法进行链接)
  • 程序编译出来,没有被加载的时候,程序内部有区域readelf -s 可执行文件可以查看区域)
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
[muxue@bt-7274:~/git/raspi/code/22-10-07_程序地址空间]$ readelf -S test
There are 30 section headers, starting at offset 0x19f8:

Section Headers:
[Nr] Name Type Address Offset
Size EntSize Flags Link Info Align
[ 0] NULL 0000000000000000 00000000
0000000000000000 0000000000000000 0 0 0
[ 1] .interp PROGBITS 0000000000400238 00000238
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.ABI-tag NOTE 0000000000400254 00000254
0000000000000020 0000000000000000 A 0 0 4
[ 3] .note.gnu.build-i NOTE 0000000000400274 00000274
0000000000000024 0000000000000000 A 0 0 4
[ 4] .gnu.hash GNU_HASH 0000000000400298 00000298
000000000000001c 0000000000000000 A 5 0 8
[ 5] .dynsym DYNSYM 00000000004002b8 000002b8
00000000000000c0 0000000000000018 A 6 1 8
[ 6] .dynstr STRTAB 0000000000400378 00000378
0000000000000059 0000000000000000 A 0 0 1
[ 7] .gnu.version VERSYM 00000000004003d2 000003d2
0000000000000010 0000000000000002 A 5 0 2
[ 8] .gnu.version_r VERNEED 00000000004003e8 000003e8
0000000000000020 0000000000000000 A 6 1 8
[ 9] .rela.dyn RELA 0000000000400408 00000408
0000000000000018 0000000000000018 A 5 0 8
[10] .rela.plt RELA 0000000000400420 00000420
00000000000000a8 0000000000000018 AI 5 23 8
[11] .init PROGBITS 00000000004004c8 000004c8
000000000000001a 0000000000000000 AX 0 0 4
[12] .plt PROGBITS 00000000004004f0 000004f0
0000000000000080 0000000000000010 AX 0 0 16
[13] .text PROGBITS 0000000000400570 00000570
00000000000001e2 0000000000000000 AX 0 0 16
[14] .fini PROGBITS 0000000000400754 00000754
0000000000000009 0000000000000000 AX 0 0 4
[15] .rodata PROGBITS 0000000000400760 00000760
000000000000005e 0000000000000000 A 0 0 8
[16] .eh_frame_hdr PROGBITS 00000000004007c0 000007c0
0000000000000034 0000000000000000 A 0 0 4
[17] .eh_frame PROGBITS 00000000004007f8 000007f8
00000000000000f4 0000000000000000 A 0 0 8
[18] .init_array INIT_ARRAY 0000000000600e10 00000e10
0000000000000008 0000000000000008 WA 0 0 8
[19] .fini_array FINI_ARRAY 0000000000600e18 00000e18
0000000000000008 0000000000000008 WA 0 0 8
[20] .jcr PROGBITS 0000000000600e20 00000e20
0000000000000008 0000000000000000 WA 0 0 8
[21] .dynamic DYNAMIC 0000000000600e28 00000e28
00000000000001d0 0000000000000010 WA 6 0 8
[22] .got PROGBITS 0000000000600ff8 00000ff8
0000000000000008 0000000000000008 WA 0 0 8
[23] .got.plt PROGBITS 0000000000601000 00001000
0000000000000050 0000000000000008 WA 0 0 8
[24] .data PROGBITS 0000000000601050 00001050
0000000000000004 0000000000000000 WA 0 0 1
[25] .bss NOBITS 0000000000601054 00001054
0000000000000004 0000000000000000 WA 0 0 1
[26] .comment PROGBITS 0000000000000000 00001054
000000000000002d 0000000000000001 MS 0 0 1
[27] .symtab SYMTAB 0000000000000000 00001088
0000000000000648 0000000000000018 28 46 8
[28] .strtab STRTAB 0000000000000000 000016d0
000000000000021e 0000000000000000 0 0 1
[29] .shstrtab STRTAB 0000000000000000 000018ee
0000000000000108 0000000000000000 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
L (link order), O (extra OS processing required), G (group), T (TLS),
C (compressed), x (unknown), o (OS specific), E (exclude),
l (large), p (processor specific)

需要注意的是,程序内部的地址,和内存的地址没有关系

可以理解为,我们程序内部都存放的是一个相对地址。编译程序的时候,认为程序是按照0000~FFFF进行编址的。

当程序被加载到内存当中时,假设系统将该程序的代码从内存0x100开始加载,就可以依照程序编址的数据加上这个偏移量,从而存放在内存中。

比如程序中有一个代码段的位置是0x1F,这时候在加载程序的时候,就会把这个代码段加上偏移量来加载

代码地址虚拟地址
0x1f0x11f
0x200x120

大概就是这样,吧哩吧啦……

2.2 写时拷贝

现在就可以来解答一下1.2中出现的问题了

image-20221007200911768

当子进程尝试修改test变量的时候,操作系统就会开始一个写时拷贝,开辟一个新的空间,将对应的值考入该空间,再重新映射页表。

这时候,虽然页表左侧的虚拟地址没有变化,但是映射的物理地址已经不一样了!

image-20221007200928695

这样就能保证父子进程的独立性,谁修改变量都互不影响!

类似C++中实现的深拷贝

2.2.1 fork两个返回值的解释

pid_t id这个变量属于父进程栈空间中定义的变量,但是fork内部,return会被执行两次(return的本质是通过寄存器将返回值写入到接收返回值的变量中)

id = fork()的时候,谁先返回,谁就会发生一次写时拷贝。所以同一个变量有不同的内容值,本质上也是同一个虚拟地址,对应了不同物理地址的体现!

  • 打印fork的返回值,即可观察到和1.2中一样的情况,虚拟地址相同,但是ret的值不同

image-20221007201647347

3.程序地址空间的作用

需要注意的是,内存作为一个硬件,没有办法拒绝你的读写!内存是不带控制功能的!

直接让用户修改物理内存风险极大:

  • 野指针问题
  • 用户可能直接修改操作系统需要用到的内存地址,导致系统boom

程序地址空间让访问内存时添加了一层软硬件层,可以对转化过程进行审核,拦截非法的访问

比如操作系统检测到进程在往虚拟地址的常量区读取数据的时候,不做阻拦;但是往常量区写入数据的时候,会进行拦截。这才是无法修改常量数据的真正原理

  • 保护内存
  • 可以使用进程管理更好的对功能模块进行解耦(linux内存管理)
  • 让程序/进程可以用统一的方式/视角来看待内存,以统一的方式编译加载所有可执行程序,简化程序本身的设计和实现

同时,程序地址空间还可以延迟用户的内存使用。比如我们现在malloc了100个字节的空间,实际上操作系统并不会立马给你申请空间,而是操作你的mm_struct让进程以为自己已经申请成功了。当程序真正使用这个空间的时候,操作系统才会去物理内存中进行映射!

申请的时候,是通过linux的内存管理模块进行操作的。同时,写时拷贝也是通过操作系统的内存管理模块来完成的!

这种“延迟访问”,可以避免某些程序申请了内存而在一段时间内没有使用的问题!避免了内存资源的无效占用(也是一种浪费)

4.页表

前面只是对页表做了一个基本的解释,但页表并不单纯进行虚拟地址和物理地址的映射,其还会增添权限,是否命中的判断,以及U/K权限的标识

image-20221217101436340

  • 权限:避免你修改const属性的数据
  • 是否命中:如果对于物理内存处没有数据,则没有命中;需要从硬盘中加载数据到内存中,将是否命中更改为是
  • U/K权限:用户级和内核级的差别,参考 linux信号 5.1中关于用户态和内核态的描述;避免用户态的进程执行内核态的源码

前面提到,每一个进程都有一个独立的程序地址空间。要是页表只有一张的话,会发生什么事呢?

32位系统为例:

  • 内存一共有2^32次方个字节,也就是4Gb
  • 假设页表每一个字节的条目需要8个字节的空间,那就需要32G的空间来存放页表
  • 页表肯定不能存在硬盘里面,但这么大的空间一般电脑的内存可放不下
  • 这也就告诉我们,页表并不是只有一张!

页表实际上是有多张的👌

4.1 分页存储

当cpu访问进程地址空间的时候,其访问的其实是虚拟地址

32位环境下,为了保证地址能覆盖到所有位置,每一个地址都有32个比特位;当MMU拿到虚拟地址的时候,其实会将虚拟地址拆分

1
2
3
10     +    10     +    12
01010101 00 01000111 11 00001011 1001
xxxxxxxx xx yyyyyyyy yy zzzzzzzz zzzz
  • 这里面的前10位会用于在页目录中,用于查找二级页表
  • 中间10位会在二级页表中查找页,指向的是页在物理内存中的起始地址
  • 最后的12字节,一共是2^12=4kb,可以覆盖单个页的大小,是单个页中的偏移量

这里又涉及到了一个知识点,那便是Linux下IO的基本单位是4kb

有了这两级的页表后,第一级页表只需要2^10个条目,第二级页表有多个,每一个也是2^10个条目,最后再指向4kb的页

linux下有专门的结构体来描述单个页,和其他系统一样,有了对单个页的描述后,我们就可以用一个数组将页给管理起来。此时对内存的管理,就转换成了对数组的增删查改

1
2
struct page
{};

页表实现了分离之后,就可以按需创建,不会出现一次性创建一个非常大的页表,导致内存空间都被占满的情况!

最初的算法其实是有问题的,因为页表的映射并不需要对每一个字节进行映射。只需要映射到4kb这一块即可,总共的条目是2^32 / 2^12 = 2^20个,所占用空间也没那么大了

4.2 加载

如果在寻址的时候,发现二级页表中所对应的page是NULL,那么代表该代码的数据没有被加载到内存中

此时就可以从硬盘中加载,并把page的首地址给映射进二级页表中

好得很

结语

关于这部分的理解其实并不算十分透彻,或许在日后的项目实践中能加深理解呢~