GCC 4.8: Bedeutet -Og -g?

Question

Vor kurzem wurde die Dokumentation für GCC 4.8 aktualisiert, die jetzt einen neuen Optimierungsschalter, -Og, einführt. Diese

[..] adressiert die Notwendigkeit für schnelle Kompilierung und eine überlegene Debugging-Erfahrung, während eine angemessene Laufzeitleistung zur Verfügung stellt. Die Gesamterfahrung für die Entwicklung sollte besser sein als die Standardoptimierungsstufe -O0.

Ist dieser Schalter implizieren -g oder habe ich es manuell zu meinem CXXFLAGS hinzufügen?

Answer 1

Kurze Antwort: Nein, Sie müssen noch -g manuell hinzufügen.

Lange Antwort:

Ich habe eine harte Antwort direkt von der Quelle finden gekämpft, so habe ich beschlossen, es selbst die hier beschriebenen Methoden verwenden zu testen: How to check if program was compiled with debug symbols?

Ich baute eine ausführbare Datei mit die -O3 Flagge und ohne -g. Die Verwendung von objdump --syms <file> | grep debug ergab nichts, wie erwartet.

Ich baute dann eine ausführbare Datei mit -g und ohne Optimierung Flags. Der gleiche Befehl objdump ergab sechs Ergebnisse wie folgt aus:

0000000000000000 l d .debug_info 0000000000000000 .debug_info

I schließlich eine ausführbare Datei mit dem -Og Flag gebaut und ohne -g. Der Befehl objdump ergab nichts. Das bedeutet, dass Debug-Symbole in diesem Fall nicht sind.

Während ich keine explizite Dokumentation von GCC selbst finden kann, die Gentoo Wiki (wie zuvor von Marco Scannadinari erwähnt) bestätigt meine Behauptung, dass -Og nicht -g bedeutet jedoch.

Answer 2

Ein Blick in den GCC 4.9.2 Quellcode (gcc/opts.c) zeigte, dass -Og die die gleiche wie -O1 ist, aber mit einigen Flags deaktiviert, die in einem schlechteren Debug-Erfahrung führen könnte:

/* in function default_options_optimization: */ 
    case OPT_Og: 
     /* -Og selects optimization level 1. */ 
     opts->x_optimize_size = 0; 
     opts->x_optimize = 1; 
     opts->x_optimize_fast = 0; 
     opts->x_optimize_debug = 1; 
     break; 

Ein paar Schritte später wird die Funktion maybe_default_option mit einer Reihe von Optionen und dem x_optimize_debug Flag aufgerufen. Optionen, die mit OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_LEVELS_1_PLUS_SPEED_ONLY und OPT_LEVELS_2_PLUS_SPEED_ONLY markiert sind, werden nicht aktiviert, wenn -Og verwendet wird.

Also hier kommt die Aussage "sollte besser sein als -O0" her. -Og ist zwischen -O0 und -O1. Dies wirkt sich nicht auf die Einbeziehung von Debuginformationen aus, die über die Optionen -g aktiviert werden. Sie würden wahrscheinlich auch Interesse an den verschiedenen -g Optionen:

• Option -ggdb Überschreibungen -g.Das heißt, wenn Sie -ggdb nach -g festlegen, wird die Option -g effektiv ignoriert.
• Option -g ist gleich -g2 und unterlassen -g ist das gleiche wie -g0.
• Option -g3 erzeugt einen größeren Debugging-Abschnitt als -g2 und so funktioniert -ggdb3 gegen -ggdb2.
• Höhere Optimierungsstufen führen beide zu einer Erhöhung der Code- und Debugging-Abschnitte. (-O1 < -Og < -O2 < -O3).
• strip --strip-debug führte zu der gleichen Objektgröße unabhängig von den -g Ebenen. Dies entsprach der Erwartung, dass nur der -O-Level eine Auswirkung auf den tatsächlichen Code hat, wobei -g die Debug-Abschnitte bestimmt.
• strip --keep-debug Ergebnisse in Objekten, in denen die Größe von der -g Ebene dominiert wird, gefolgt von -O Ebenen. (So ​​ist -g0 -O3 kleiner als -g3 -O0).

Hinweis: hier habe ich nicht über die Zeit zu kompilieren. Es wird wahrscheinlich mit aggressiveren Optimierungsstufen zunehmen. Ich würde erwarten, dass die Debug-Levels nur einen geringen Einfluss auf die Zeit haben (im Vergleich zur Optimierung), da es nur bedeutet, dass zusätzliche Details während des Durchlaufs verfolgt werden müssen.

Hier ist der Befehl, ich verwenden, um das tatsächliche Verhalten zu testen (vergleiche auch -ggdbX statt -gX):

for g in -g0 -g2 -g3;do 
    for O in -O0 -O1 -O2 -O3 -Og; do 
     flags="$g $O"; 
     gcc -fPIC -rdynamic -c -Wall -Wextra -Ilib ltunify.c -o obj/gL_"${flags// /_}_.o" $flags || break; 
    done; 
done