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

Question

我正在从事一个依赖劳特巴赫 JTAG 调试器硬件和软件的项目，目标 JTAG 电缆的支持已于 2011 年 7 月结束。我们在 omap2 处理器上使用 Linux 2.6.33 内核。我们正在使用 gcc 4.9.2 构建内核镜像(不确定是什么版本的 bintools)。

对于那些不熟悉 Lauterbach 如何许可其软件的人，目标电缆(连接调试器和目标之间)带有支持契约(Contract)日期。可以使用在支持期之前和之前的任何版本的 Lauterbach Trace-32 软件，但是在电缆支持结束之后，除了每个 session 30 分钟的演示期外，不得使用任何版本。我们正在通过我们的采购流程来续签电缆的支持契约(Contract)，但在完成之前(可能需要几个月)，我们只能使用现有的东西。

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

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

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

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

当然，最简单的解决方案是更新到支持我们工具链生成的任何 ELF/DWARF 组合的第一个 Trace-32 软件版本。我们知道最新版本有效，但我们的电缆不支持该版本，并且直到我们的采购人员弄清楚这是测试设备还是软件(他们的预算不同)后才会支持。

在接下来的几个月里，我们需要一个变通办法。我正在寻找以下其中一项:

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

我提前感谢大家的帮助。

Edit: I'm not 100% sure whether the toolchain is producing DWARF3 or DWARF4, so it may be that I need to make a ELF/DWARF2 "vmlinux"

Answer 1

你的三个想法:

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