1

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

对于那些不熟悉劳特巴赫如何为其软件授权的人，目标电缆（连接调试盒和目标）带有支持合同日期。任何版本的 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)

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

在接下来的几个月里，我们需要一个变通办法。我正在寻找以下内容之一：

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

我提前感谢大家的帮助。

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

4

1 回答 1

3

对你的三个想法：

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