GCC 4.8 : -Og는 -g를 의미합니까?

Question

최근 GCC 4.8의 설명서가 업데이트되어 새로운 최적화 스위치 인 -Og이 도입되었습니다. 이

[..]는 적절한 수준의 런타임 성능을 제공하면서 빠른 컴파일 및 우수한 디버깅 환경에 대한 필요성을 해결합니다. 전반적인 개발 경험은 기본 최적화 수준 -O0보다 우수해야합니다.

이 스위치는 -g을 의미 하는가 아니면 수동으로 CXXFLAGS에 추가해야합니까?

Answer 1

짧은 대답 : 아니요, 수동으로 -g을 수동으로 추가해야합니다.

긴 대답는 :

나는 소스로부터 직접 하드 답을 찾기 위해 분투, 그래서 여기에 설명 된 방법을 사용하여 자신을 테스트하기로 결정 How to check if program was compiled with debug symbols?

나는 함께 실행 파일을 내장 -O3 플래그가없고 -g없이 objdump --syms <file> | grep debug을 사용하면 예상대로 아무 것도 산출되지 않았습니다.

그런 다음 최적화 플래그없이 -g과 함께 실행 파일을 만들었습니다.

0000000000000000 l d .debug_info 0000000000000000 .debug_info

내가 마지막으로 -Og 플래그 및 -g없이 실행 파일을 내장 : 같은 objdump 명령은이 6 개 개의 결과를 얻었다. objdump 명령은 아무것도 산출하지 않았습니다. 즉,이 경우 디버그 기호는 이 아니고이 아닙니다. 내가 GCC 자체에서 명시 적 문서를 찾을 수는 없지만 -Og이 -g을 의미하지 않는다는 것을

는 (마르코 Scannadinari으로 앞서 언급 한대로) Gentoo Wiki 내 주장을 확인합니다.

Answer 2

(GCC/opts.c가) -Og이 -O1과 동일하지만 것을 보여 GCC 4.9.2 소스 코드에서 보면 일부 플래그는 나쁜 디버깅 경험을 초래할 수있는 비활성화로 :

/* 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; 

몇 단계 후, maybe_default_option 함수를 호출하고 x_optimize_debug 플래그를 사용하여 호출합니다. 을 사용하면 OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_LEVELS_1_PLUS_SPEED_ONLY 및 OPT_LEVELS_2_PLUS_SPEED_ONLY으로 표시된 옵션을 사용할 수 없습니다.

이렇게하면 "~ O0보다 좋다"라는 문구가 나타납니다. -Og은 -O0과 -O1 사이에 있습니다. 이 옵션은 -g 옵션을 통해 활성화 될 수있는 디버깅 정보를 포함시키는 데 영향을 미치지 않습니다. 당신은 아마 또한 다른 -g 옵션에 관심이있을 것입니다 :

• 옵션 -ggdb 무시 -g.즉, -g 이후에 -ggdb을 설정하면 -g 옵션이 실제로 무시됩니다.
• 옵션 -g은 -g2이고, -g을 생략하면 -g0과 같습니다.
• 옵션 -g3은 -g2보다 큰 디버깅 섹션을 생성하므로 을 -ggdb2과 비교하여 더 큰 디버깅 섹션을 생성합니다.
• 최적화 수준이 높을수록 코드 및 디버깅 섹션이 증가합니다. (-O0 < -O1 < -Og < -O2 < -O3).
• strip --strip-debug은 -g 레벨과 관계없이 동일한 개체 크기를 나타냅니다. 이는 -O 레벨 만 실제 코드에 영향을 미치므로 -g이 디버그 섹션을 결정한다는 기대치와 일치했습니다.
• strip --keep-debug은 크기가 -g 수준이며 그 다음에 -O 수준이 우세한 개체가됩니다. (따라서 -g0 -O3은 -g3 -O0보다 작음).

참고 : 여기서 컴파일 시간을 고려하지 않았습니다. 보다 적극적인 최적화 수준으로 증가 할 가능성이 높습니다. 디버그 레벨은 (최적화에 비해) 시간에 미미한 영향을 미칠 것이라고 기대할 수 있습니다. 이는 단지 패스 중에 추가 세부 사항을 추적해야한다는 것을 의미하기 때문입니다. 여기

내가 실제 동작을 테스트하는 데 사용되는 명령입니다 (또한 -ggdbX 대신 -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