【问题标题】:GCC option that can cause trouble when debugging with GDB使用 GDB 进行调试时可能导致问题的 GCC 选项
【发布时间】:2010-02-11 17:16:59
【问题描述】:

我想知道我是否可以获得可能导致 gdb 行为异常的 gcc 选项列表。

当然,我们都知道使用优化选项(例如 -O3)会导致 gdb 出现奇怪的行为,但还有哪些其他选项会产生这种影响?

(我目前正在尝试在 gdb 中运行 mpeg2 解码器,即使在删除优化标志后我也会出现奇怪的行为......)

【问题讨论】:

  • 描述怪异的。你添加了-ggdb吗?最重要的是:写下您仍在使用哪些选项。
  • 只使用过 -g 和 -g3。在我的例子中,奇怪的行为是这样的:一个函数定义从第 654 行开始,'n' 然后跳转到第 765 行,另一个 'n' 跳回第 654 行等等 4 或 5 次,当然,行765 不应该是下一个……但是即使我现在正在寻找导致此问题的标志,我也对可能导致更普遍的奇怪行为的不同选项感到好奇。
  • 对于我仍在使用的选项,有很多安静,我没有在我的问题中发布它们,而是使其更笼统。
  • 一般来说,你最好提出一个更具体的问题。听起来像内联或循环展开。
  • 那我明天上班时把剩下的旗子贴出来。

标签: gcc gdb flags


【解决方案1】:

我认为很难说在调用 gcc 进行调试时不应该使用哪些标志。 gcc docs 注意默认调试标志是-g-O2,使用-g -O0 -fno-inline 会禁用任何优化和函数内联。

在我看来,如果你真的想保证不会弄乱你的调试过程,你只需要使用-g -O0 -fno-inline 标志进行编译。

【讨论】:

  • 如果同时有 -O3 标志、其他标志和“-g -O0 -fno-inline”会怎样?
  • 我制作了一个简单的程序并使用 -O3 -g -O0 -fno-inline -S 和 -g -O0 -fno-inline -S 的输出相同。但是使用 -g -O0 -fno-inline -O3 -S 的输出是不同的,在这种情况下,带有 -O3 的汇编代码比没有 -O3 生成的代码大。我还不知道这个结果的含义。
  • 毫不奇怪,在第一种情况下,-O0 会覆盖 -O3。 gcc 手册页说:“如果您使用多个 -O 选项,无论有无级别编号,最后一个这样的选项都是有效的。”
【解决方案2】:

GCC documentation 中所述,您应该使用 -Og:

-Og

优化调试体验。 -Og 启用不干扰调试的优化。它应该是标准编辑-编译-调试周期的首选优化级别,提供合理的优化级别,同时保持快速编译和良好的调试体验。

它还描述了每个优化标志以及它如何影响调试。

【讨论】:

  • 原则上是的,实际上-O0 可能更可取
猜你喜欢
  • 2021-05-05
  • 1970-01-01
  • 1970-01-01
  • 2016-09-02
  • 1970-01-01
  • 1970-01-01
  • 2020-03-11
  • 2023-03-14
相关资源
最近更新 更多