c - 为什么在 Linux 上字符串文字的内存地址与其他的如此不同？

Question

我注意到字符串文字在内存中的地址与其他常量和变量(Linux 操作系统)有很大不同:它们有许多前导零(未打印)。

例子:

const char *h = "Hi";
int i = 1;
printf ("%p\n", (void *) h);
printf ("%p\n", (void *) &i);

输出:

0x400634
0x7fffc1ef1a4c

我知道它们存储在可执行文件的 .rodata 部分中。操作系统之后是否有一种特殊的方式处理它，所以文字最终会出现在一个特殊的内存区域(带有前导零)？该内存位置有什么优点吗？或者它有什么特别之处？

Answer 1

这是 Linux 上进程内存的布局方式(来自 http://www.thegeekstuff.com/2012/03/linux-processes-memory-layout/):

.rodata 部分是Initialized Global Data block 的写保护子部分。 (ELF 可执行文件指定 .data 的部分是初始化为非零值的可写全局变量的可写对应部分。初始化为零的可写全局变量转到 .bss block 。通过这里的 globals 是指全局变量和所有 静态 变量，无论其位置如何。)

图片应该解释你的地址的数值。

如果您想进一步调查，那么在 Linux 上，您可以检查 /proc/$pid/maps 描述正在运行的进程的内存布局的虚拟文件。您不会得到保留(以点开头)的 ELF 部分名称，但您可以通过查看其内存保护标志来猜测内存块源自哪个 ELF 部分。例如，运行

$ cat /proc/self/maps #cat's memory map

给我

00400000-0040b000 r-xp 00000000 fc:00 395465                             /bin/cat
0060a000-0060b000 r--p 0000a000 fc:00 395465                             /bin/cat
0060b000-0060d000 rw-p 0000b000 fc:00 395465                             /bin/cat
006e3000-00704000 rw-p 00000000 00:00 0                                  [heap]
3000000000-3000023000 r-xp 00000000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000222000-3000223000 r--p 00022000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000223000-3000224000 rw-p 00023000 fc:00 3026487                        /lib/x86_64-linux-gnu/ld-2.19.so
3000224000-3000225000 rw-p 00000000 00:00 0
3000400000-30005ba000 r-xp 00000000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30005ba000-30007ba000 ---p 001ba000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007ba000-30007be000 r--p 001ba000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007be000-30007c0000 rw-p 001be000 fc:00 3026488                        /lib/x86_64-linux-gnu/libc-2.19.so
30007c0000-30007c5000 rw-p 00000000 00:00 0
7f49eda93000-7f49edd79000 r--p 00000000 fc:00 2104890                    /usr/lib/locale/locale-archive
7f49edd79000-7f49edd7c000 rw-p 00000000 00:00 0
7f49edda7000-7f49edda9000 rw-p 00000000 00:00 0
7ffdae393000-7ffdae3b5000 rw-p 00000000 00:00 0                          [stack]
7ffdae3e6000-7ffdae3e8000 r--p 00000000 00:00 0                          [vvar]
7ffdae3e8000-7ffdae3ea000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]

第一个 r-xp block 肯定来自 .text(可执行代码)， .rodata 中的第一个 r--p block ，以及 .bss 中的以下 rw-- block 和.数据。 (在堆和堆栈 block 之间是动态链接器从动态链接库中加载的 block 。)

---

注意:为了符合标准，您应该将 "%p" 的 int* 转换为 (void* ) 否则行为未定义。