构建 Linux 内核映像 (vmlinux) 以使用 DWARF3 而不是 DWARF4

Question

我正在开发一个依赖于 Lauterbach JTAG 调试器硬件和软件的项目，对目标 JTAG 电缆的支持已于 2011 年 7 月终止。我们在 omap2 处理器上使用 Linux 2.6.33 内核。我们使用 gcc 4.9.2 来构建内核映像（不确定 bintools 的版本）。

对于那些不熟悉 Lauterbach 如何许可其软件的人来说，目标电缆（连接调试器和目标之间）带有支持合同日期。可以使用支持期之前和支持期结束之前的任何版本的 Lauterbach Trace-32 软件，但电缆支持结束后的任何版本都不能使用，每次会话 30 分钟的演示期除外。我们正在通过采购流程来续签电缆的支持合同，但在完成之前（可能需要几个月的时间），我们只能坚持现有的条件。

看来我们使用的工具链生成的调试信息对于 2017 年 7 月之前发布的 Trace-32 调试器软件的最后一个版本来说太新了。尝试使用以下命令加载内核映像 (vmlinux) 的符号：

data.load.elf \\path\to\vmlinux /nocode

失败并显示类似以下内容的消息：

error: entry near offset 5432100. in file \\path\to\vmlinux (use DUMP)

当然，最简单的解决方案是更新到 Trace-32 软件的第一个版本，该版本支持我们的工具链生成的任何 ELF/DWARF 组合。我们知道最新版本可以工作，但我们的电缆不支持该版本，并且直到我们的采购人员确定这是测试设备还是软件（它们来自不同的预算）之后才会支持。

在接下来的几个月里，我们需要一个解决方法。我正在寻找以下其中一项：

1. 告诉工具链生成与调试器软件兼容的调试信息的某种方式
2. 将我们的工具链生成的 vmlinux ELF/DWARF 文件转换为早期 ELF/DWARF 格式修订版的某种方法，该修订版与我们被迫使用的 Trace-32 版本兼容 (R.2010.11.000028724)。
3. 我们没有想到的问题的任何其他解决方案

我预先感谢大家的帮助。

编辑：我不是 100% 确定工具链是生成 DWARF3 还是 DWARF4，所以我可能需要制作一个 ELF/DWARF2“vmlinux”

Answer 1

对于您的三个想法：

1. 我建议尝试 GCC 的选项：-g -gdwarf-2 -gstrict-dwarf
   或者您可以尝试 gcc 版本 4.4（或更早版本），它似乎适合 2011 年。
2. 我认为你根本没有机会将 ELF 的 DWARF 信息转移到其他东西上。（或者至少不是以某种简单的方式。）
3. 访问劳特巴赫网站。在支持 > 注册处，您可以申请一个月的临时维护密钥。这应该让您的销售人员有时间购买新钥匙。