Ich verwende derzeit gdb, um die Auswirkungen von Low-Level-Code zu sehen. Im Moment mache ich folgendes:
%Vor% Wenn ich den Speicher mit info proc mappings in gdb untersuche, sehe ich nach dem, was ich vermute, den .text-Abschnitt (da Objfile den Namen des binären Debuggers anzeigt):
Wie kommt es, dass der Haufen so groß ist, wenn ich nur Platz für ein einzelnes int zugewiesen habe?
Die seltsamste Sache ist, auch wenn ich calloc(1000, sizeof(int)) mache, bleibt die Größe des Heaps gleich.
PS: Ich benutze Ubuntu 14.04 auf einem x86_64-Rechner. Ich kompiliere die Quelle mit g ++ (ja, ich weiß, ich sollte Calloc in C ++ nicht verwenden, das ist nur ein Test).
Wie kommt es, dass der Haufen so groß ist, wenn ich nur Platz für ein einzelnes int zugewiesen habe?
Ich habe einen einfachen Test unter Linux gemacht. Wenn man calloc glibc aufruft, wird irgendwann sbrk () aufgerufen, um Speicher vom Betriebssystem zu holen:
Aber glibc fragt das Betriebssystem nicht nach genau 4 Bytes, die Sie angefordert haben. glibc berechnet seine eigene Größe. So wird es in glibc gemacht:
mp_.top_pad ist standardmäßig 128 * 1024 Bytes, also ist es der Hauptgrund, warum das System, wenn Sie nach 4 Bytes fragen, 0x21000 Bytes zuweist.
Sie können mp_.top_pad mit dem Aufruf von mallopt anpassen. Dies ist aus dem Dokument von mallopt:
Also habe ich Ihr Programm geändert und mallopt hinzugefügt:
%Vor% Ich setze 1 Byte padding und laut doc muss es be always rounded to a system page boundary sein.
Das sagt mir gdb für mein Programm:
%Vor%Also jetzt ist der Heap 4096 Bytes. Genau die Größe meiner Seite:
%Vor%Nützliche Links:
Da Sie C / C ++ erwähnt haben, verwenden Sie besser das folgende Konstrukt:
%Vor%