Variableninitialisierung beim GCC debug versus release Modus

Gast #2578872
Lesenswert?
• ▲
▼
Gibt es eigentlich beim GCC Unterschiede bei der 
Variableninitialisierung zwischen dem Debug-Modus (-g) und dem 
Release-Modus?

Automatische Variablen innerhalb von Funktionen sind ja prinzipiell 
nicht initialisiert. Mir kommt es aber vor, dass beim Debuggen eine 
angelegte Variable immer 0 ist.

Ich habe jetzt aber ein Problem, das auf nichtinitialiserte Variablen im 
Produktions-Code hindeuted.

Hat jemand verläßliche Informationen?

Danke, der Adib.
Moderator Persönliche Seite #2578915
Lesenswert?
• ▲
▼
Adib schrieb:
> Automatische Variablen innerhalb von Funktionen sind ja prinzipiell
> nicht initialisiert. Mir kommt es aber vor, dass beim Debuggen eine
> angelegte Variable immer 0 ist.

Zufall.

Du schreibst nicht, auf welcher Plattform das passiert.  Falls es
sich um ein Mehrnutzer-Betriebssystem handelt, dann werden alle
memory pages, bevor sie dem Prozess überlassen werden, normalerweise
ausgenullt, damit keine sicherheitsrelevanten Informationen anderer
Prozesse darin vorhanden sind.  Da bei abgeschalteter Optimierung
(-O0) prinzipiell alle Variablem im Stackframe angelegt werden,
bleibt natürlich ein großer Teil des Stacks dann auf diesen Nullen
sitzen.

GCC unterscheidet übrigens nicht zwischen "debug mode" und "release
mode".  Optimierung und Anlegen von Debuginformationen sind völlig
voneinander unabhängig; auch bei aggressivser Optimierung (-O2 oder
-O3) kann man immer noch Debuginformationen (-g) anlegen lassen und
den Debugger darauf laufen lassen.
Persönliche Seite #2578931
Lesenswert?
• ▲
▼
Jörg Wunsch schrieb:

> GCC unterscheidet übrigens nicht zwischen "debug mode" und "release
> mode".  Optimierung und Anlegen von Debuginformationen sind völlig
> voneinander unabhängig; auch bei aggressivser Optimierung (-O2 oder
> -O3) kann man immer noch Debuginformationen (-g) anlegen lassen und
> den Debugger darauf laufen lassen.

Was auf jeden Fall gilt ist:

-g, also debug-Info anlegen ja/nein, hat keinen Einfluß auf den 
erzeugten Code. Falls doch, ist das als Compilerfehler anzusehen.

Andersrum ist das nicht ganz so klar, d.h. ich würd meine Hand nicht 
dafür ins Feuer legen, daß Optimierung keinen Einfluß auf das Erzeugen 
von Debug-Info hat.

Zeitgemäße Debug-Formate wie DWARF-4 bieten zwar Unterstützung für 
optimierten Code, so wird zum Beispiel in
1
void foo (void)
2
{
3
    int var = 1;
4
}
das Setzen von var in der Debug-Info dokumentiert auch wenn die 
Zuweisung selbst weggeworfen und var nicht angelegt wird.

Ob -O* jedoch komplett neutral in Bezug auf Degug-Info ist würd ich 
nach GCC-Intuition verneinen.
Moderator Persönliche Seite #2578959
Lesenswert?
• ▲
▼
Adib schrieb:
> Das Problem, das ich habe ist auf einem Linux Rechner mit GCC. Ich
> dachte, das der GCC auf jeder Platform quasi gleich funktioniert.

Der GCC (im Prinzip) schon.

Das Betriebssystem nicht.  Wie schon beschrieben, nullt dein Linux
alle memory pages aus, bevor sie der Prozess bekommt.  Wenn du ein
äquivalentes Programm auf einem Mikrocontroller ohne System laufen
lässt, dann sieht die Applikation hingegen zufällige RAM-Inhalte.

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.