Warum unterscheiden sich die Speicheradressen von String-Literalen unter Linux so stark von denen anderer?

Mir ist aufgefallen, dass String-Literale ganz andere Adressen im Speicher haben als andere Konstanten und Variablen (Linux OS): Sie haben viele führende Nullen (nicht gedruckt).

Beispiel:

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

Ausgabe:

0x400634
0x7fffc1ef1a4c

Ich weiß, dass sie in der gespeichert sind .rodata Teil der ausführbaren Datei. Gibt es eine spezielle Art und Weise, wie das Betriebssystem danach damit umgeht, sodass die Literale in einem speziellen Speicherbereich (mit führenden Nullen) landen? Hat dieser Speicherort Vorteile oder ist etwas Besonderes daran?

So ist der Prozessspeicher unter Linux aufgebaut (von http://www.thegeekstuff.com/2012/03/linux-processes-memory-layout/):

Das .rodata Abschnitt ist ein schreibgeschützter Unterabschnitt der Initialisierte globale Daten Block. (Ein Abschnitt, der ELF ausführbare Dateien benennen .Daten ist sein beschreibbares Gegenstück für beschreibbare globale Werte, die mit Werten ungleich Null initialisiert wurden. Beschreibbare Globals, die mit Nullen initialisiert werden, gehen an die .bss Block. Mit Globals meine ich hier globale Variablen und alles statisch Variablen unabhängig von der Platzierung.)

Das Bild soll die Zahlenwerte Ihrer Adressen erklären.

Wenn Sie weiter nachforschen möchten, können Sie unter Linux die
/proc/$pid/maps virtuelle Dateien, die das Speicherlayout laufender Prozesse beschreiben. Sie erhalten nicht die reservierten (mit einem Punkt beginnenden) ELF-Abschnittsnamen, aber Sie können erraten, aus welchem ​​ELF-Abschnitt ein Speicherblock stammt, indem Sie sich seine Speicherschutz-Flags ansehen. Laufen zum Beispiel

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

gibt mir

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]

Der Erste r-xp Block kam definitiv von .Text (ausführbarer Code), der erste r--p abblocken .rodataund die folgende rw– Blöcke ab .bss und .Daten. (Zwischen dem Heap- und dem Stack-Block befinden sich Blöcke, die vom dynamischen Linker aus dynamisch verknüpften Bibliotheken geladen werden.)

Notiz: Um der Norm zu entsprechen, sollten Sie die gießen int* zum "%p" zu (void*) oder das Verhalten ist undefiniert.

Das liegt daran, dass Zeichenfolgenliterale haben statische Speicherdauer. Das heißt, sie werden während des gesamten Programms leben. Solche Variablen können an einem speziellen Speicherplatz gespeichert werden, der sich weder auf dem sogenannten Heap noch auf dem Stack befindet. Daher die unterschiedlichen Adressen.

Denken Sie daran, dass wo ein Zeiger war ist unterscheidet sich von wo ein Zeiger verweist auf. Ein realistischerer (Äpfel-zu-Äpfel) Vergleich wäre

printf ("%p\n", (void *) &h);
printf ("%p\n", (void *) &i);

Ich vermute, Sie werden das finden h und p ähnliche Adressen haben. Oder ein anderer, realistischerer Vergleich wäre

static int si = 123;
int *ip = &si;
printf ("%p\n", (void *) h);
printf ("%p\n", (void *) ip);

Ich vermute, Sie werden das finden h und ip weisen auf eine ähnliche Erinnerungsregion hin.

Bedenken Sie, dass Literale schreibgeschützte Variablen sind und dass es auch ein Konzept eines Literalpools gibt. Der Literal-Pool ist eine Sammlung der eindeutigen Literale des Programms, in der doppelte Konstanten verworfen werden, wenn Referenzen zu einer zusammengeführt werden.

Es gibt einen Literal-Pool für jede Quelle, und abhängig von der Ausgereiftheit des Link-/Bind-Programms können Literal-Pools nebeneinander platziert werden, um eine .rodata-Datei zu erstellen.

Es gibt auch keine Garantie dafür, dass der Literal-Pool schreibgeschützt ist. Sprache, obwohl Compiler-Designs es so behandeln.

Betrachten Sie mein Codefragment. ich könnte haben

const char *cp=”Hallo Welt”;
const char *cp1=”Hallo Welt”;

Der gute Compiler wird das in diesem Quellcode erkennen, die schreibgeschützten Literale CP, CP1zeigen auf identische Zeichenfolgen und lassen cp1 auf das Literal von cp zeigen, wobei das zweite verworfen wird.

Noch ein Punkt. Der Literalpool kann ein Vielfaches von 256 Bytes oder ein anderer Wert sein. Wenn die Pooldaten kleiner als 256 Bytes sind, wird der Schlupf mit hexadezimalen Nullen aufgefüllt.

Verschiedene Compiler folgen gemeinsamen Entwicklungsstandards, die es ermöglichen, ein Modul mit zu kompilieren Cum mit einem kompilierten Modul verknüpft zu werden Assemblersprache oder andere Sprache. Die beiden Literal-Pools werden nacheinander in .rodata abgelegt.

printf ("%p\n", h); // h is the address of "Hi", which is in the rodata or other segments of the application.
printf ("%p\n", &i); // I think "i" is not a global variable, so &i is in the stack of main. The stack address is by convention in the top area of the memory space of the process.