Variableninitialisierung beim GCC debug versus release Modus

[Adib (Gast)]

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.

[Peter II (Gast)]

ich kann es nur vom MS-compiler sagen, da ist es so das im debug alle 
Variabel den wert 0 haben. Also durchaus möglich das es im GCC genauso 
ist.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Johann L. (gjlayde)]

auto-Variablen ohne Initializer sind nicht initialisiert. Sich auf was 
anderes zu verlassen oder aus Beispielen ein "Gewohnheitsrecht" 
abzuleiten in Hack.

[Johann L. (gjlayde)]

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

void foo (void)
{
    int var = 1;
}

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.

[Adib (Gast)]

Das Problem, das ich habe ist auf einem Linux Rechner mit GCC. Ich 
dachte, das der GCC auf jeder Platform quasi gleich funktioniert.

Adib.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Reinhard R. (reinhardr)]

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

Verwendest du ein Tool zur statischen Codeanalyse (Lint, Cppcheck etc.)? 
Wenn nicht, probiere das einmal aus.

Reinhard

[Rolf M. (rmagnus)]

Und mal in valgrind (Memorydebugger) laufen lassen.