Angenommen, ich habe diesen Code:
%Vor% Wir wissen, dass das tatsächliche Speicherlayout in folgende Segmente aufgeteilt wird: .text
, .bss
, .data
, .heap
, .stack
.
Ich weiß, wie man objdump
, readelf
usw. benutzt. Aber ich möchte eine bessere Sicht auf den Speicher-Stack bekommen, wo ich Dinge sehen kann wie:
Der wichtigste Punkt ist: Die tatsächlichen Variablennamen fehlen in der Ausgabe von objdump
, readelf
etc.
Ich kompiliere diesen Code mit -g
und behalte so die Symboltabelle.
Warum kann ich dann nicht das Speicherlayout mit lokalen / globalen Variablennamen sehen?
objdump -x
zeigt die Namen der Variablen, wenn der Typ static
ist, andernfalls nicht. Warum?
Es gibt wenige Methoden, um die Speicherzuordnung zu verfolgen, aber keine davon ist eine integrierte Methode und alle erfordern zusätzliche Arbeit auf Ihrer Seite. Um Speicher zu visualisieren, müssen Sie Code-Instrumentierung und / oder Ereignisprotokollierung verwenden, d. H. Speicherzuordnungs- und -freigabeereignisse, und dann alle Ereignisse erneut abspielen und daraus Graphen erzeugen.
Sehen Sie sich dieses Papier an: Visualisierung von dynamischen Speicherzuordnungen (in C-Programmen) .
GCSpy (für Heap-Visualisierung) ist hier verfügbar: Ссылка . Während sie ursprünglich für JVM verwendet wurden, können Sie den Heap eines C-Programms beispielsweise mit dlmalloc
visualisieren.
Ich verstehe völlig, warum du das machen willst - ich habe nach dem gleichen gesucht. Obwohl ich das Speicherlayout-Snapshotting an sich nicht sehr nützlich finde, finde ich, dass das Beobachten, wie Speicher im Laufe der Zeit zugewiesen wird, sehr interessant und nützlich für das Debuggen von Leistungsproblemen ist.
Ich erinnere mich, dass XCode einige Instrumente zur Instrumentierung eingebaut hatte - sie wurden jedoch nie benutzt, aber es lohnt sich vielleicht zu erkunden, was sie anbieten.
Es tut mir leid, dass Sie ein bisschen verwirrt sind. Überlegen Sie:
static
-Variablen enden wahrscheinlich in einem initialisierten oder nicht initialisierten Datensegment - das hängt davon ab, ob das ursprüngliche Bitmuster vollständig 0s ist und ob der Compiler sich davon zur Kompilierungszeit überzeugen kann. Wenn Sie das oben Gesagte verstehen, brauchen Sie nichts, um ein Diagramm auf einer Variablenbasis zu zeichnen. Sie wissen sofort, welche Art von Speicher Sie verwenden.
Tags und Links c memory debug-symbols