GCC 4.8：-Og 是否暗示 -g？答案

【问题标题】：GCC 4.8: Does -Og imply -g?GCC 4.8：-Og 是否暗示 -g？
【发布时间】：2012-10-09 20:27:27
【问题描述】：

最近更新了 GCC 4.8 的文档，现在引入了一个新的优化开关，-Og。这个

[..] 满足快速编译和卓越调试体验的需求，同时提供合理水平的运行时性能。开发的整体体验应该优于默认优化级别-O0。

这个开关是暗示-g 还是我必须手动将它添加到我的CXXFLAGS？

【问题讨论】：

显然不是“请注意 -Og 并不意味着 -g，它只是禁用可能会干扰调试的优化。” - Gentoo 维基
如果有一些东西可以证明这两种说法中的任何一种，也许是来自 gcc 的一些代码摘录，那就太好了？如果作为答案发布，我将接受并投票。

标签： gcc

【解决方案1】：

查看 GCC 4.9.2 源代码 (gcc/opts.c) 表明 -Og 与 -O1 相同，但禁用了一些可能导致更差调试体验的标志：

/* 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 标记的选项在使用-Og 时不会启用。

这就是“应该比-O0更好”的说法的来源。 -Og 介于 -O0 和 -O1 之间。这不会影响包含将通过-g 选项启用的调试信息。您可能还会对不同的 -g 选项感兴趣：

选项-ggdb 覆盖-g。也就是说，如果在-g 之后设置-ggdb，-g 选项实际上会被忽略。
选项-g 等于-g2，省略-g 与-g0 相同。
选项-g3 产生比-g2 更大的调试部分，-ggdb3 对-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

【讨论】：

【解决方案2】：

简答：不，您仍然必须手动添加-g。

长答案：

我一直在努力从源头直接找到一个硬性答案，所以我决定使用此处描述的方法自己测试它：How to check if program was compiled with debug symbols?

我构建了一个带有-O3 标志但没有-g 的可执行文件。正如预期的那样，使用 objdump --syms <file> | grep debug 没有产生任何结果。

然后我使用-g 构建了一个可执行文件，并且没有任何优化标志。同样的objdump 命令产生了六个结果，如下所示：

0000000000000000 l d .debug_info 0000000000000000 .debug_info

我最终构建了一个带有-Og 标志但没有-g 的可执行文件。 objdump 命令没有产生任何结果。这意味着在这种情况下不存在调试符号。

虽然我无法从 GCC 本身找到任何明确的文档，但 Gentoo Wiki（如 Marco Scannadinari 之前提到的）证实了我的断言，即 -Og 并不暗示 -g。

【讨论】：

【解决方案3】：

fedora 29 工作站 x86_64 上的 gcc --version gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2) 手册。

不同的版本，但我认为它很有帮助。

调试程序的选项

...
  If you are not using some other optimization option, consider using -Og with -g.  With no -O option at
  all, some compiler passes that collect information useful for debugging do not run at all, so that -Og may
  result in a better debugging experience.
...

控制优化的选项

...
  -Og Optimize debugging experience.  -Og enables optimizations that do not interfere with debugging. It
      should be the optimization level of choice for the standard edit-compile-debug cycle, offering a
      reasonable level of optimization while maintaining fast compilation and a good debugging experience.
...

所以，我们可以看到-Og 是优化选项之一。 如果您没有使用其他优化选项，请考虑使用 -Og 和 -g。

示例：

#include <stdio.h>

int main(int argc, char *argv[]) {
    int n;

    for (n=0; n<10; n++) {
       printf("Print Number: %d\n", n);
    }
    return 0;
}

编译：

[user@localhost myctest]$ gcc sample.c -o sample
[user@localhost myctest]$ gcc sample.c -o sample.Og -Og
[user@localhost myctest]$ gcc sample.c -o sample.g -g
[user@localhost myctest]$ gcc sample.c -o sample.Og.g -Og -g

然后就可以看到编译后文件的大小了：

[user@localhost myctest]$ ls -l --human-readable sample*
-rwxrwxr-x. 1 user user 18K Aug 10 19:43 sample
-rw-rw-r--. 1 user user 162 Aug 10 19:43 sample.c
-rwxrwxr-x. 1 user user 21K Aug 10 19:43 sample.g
-rwxrwxr-x. 1 user user 18K Aug 10 19:43 sample.Og
-rwxrwxr-x. 1 user user 21K Aug 10 19:44 sample.Og.g

然后您可以使用readelf(GNU readelf 版本 2.31.1-13.fc29) 重新检查这些文件中的调试信息。

[user@localhost myctest]$ readelf --debug-dump=aranges sample
[user@localhost myctest]$ readelf --debug-dump=aranges sample.g
Contents of the .debug_aranges section:

  Length:                   44
  Version:                  2
  Offset into .debug_info:  0x0
  Pointer Size:             8
  Segment Size:             0

    Address            Length
    0000000000401126 000000000000003d 
    0000000000000000 0000000000000000 

[user@localhost myctest]$ readelf --debug-dump=aranges sample.Og
[user@localhost myctest]$ readelf --debug-dump=aranges sample.Og.g
Contents of the .debug_aranges section:

  Length:                   44
  Version:                  2
  Offset into .debug_info:  0x0
  Pointer Size:             8
  Segment Size:             0

    Address            Length
    0000000000401126 0000000000000028 
    0000000000000000 0000000000000000

您可以看到仅通过-Og选项编译的文件中没有调试信息。您还可以使用readelf --debug-dump= 选项查看更多信息。例如readelf --debug-dump=aranges,info sample.g。还有readelf --headers sample.g | grep debug

见man readelf:

--debug-dump[=rawline,=decodedline,=info,=abbrev,=pubnames,=aranges,=macro,=frames,=frames-interp,=str,=loc,=Ranges,=pubtypes, =trace_info,=trace_abbrev,=trace_aranges,=gdb_index,=addr,=cu_index,=links,=follow-links]

可以使用gdb来检查：

[user@localhost myctest]$ gdb sample.Og
GNU gdb (GDB) Fedora 8.2-3.fc29
Copyright (C) 2018 Free Software Foundation, Inc.
...

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from sample.Og...(no debugging symbols found)...done.
(gdb)

然后你会得到 (no debugging symbols found) 文件，sample.Og。

4.8.x

对于 4.8.x 文档，-Og 未在 Debugging-Options 部分中提及，仅在 Optimize-Options 部分中介绍。

【讨论】：