c - 如何修复 68HC11 编译器生成无效的 JMP/BRA 代码

标签 c assembly opcode 68hc11 hi-tech-c

我正在编译 C 代码,用于对设备的 EPROM 进行编程。使用的编译器是 Hi-Tech C 编译器。我相信它是 7.80 版本。

当我(重新)编写代码时,它会生成一个二进制 (*.BIN) 文件,用于刷新到 EPROM。

我发现编译后的代码通常在程序集中只有一行,这会破坏代码并导致设备在到达时关闭。编译器似乎正在更改 Branch-Always (BRA) 语句以错误地执行 BRA 0,当转换为十六进制操作码时,编译器会将其转换为 JMP 0000 。这会导致代码到达代码的意外区域,从而导致设备关闭。

当重新编写代码时,这个错误的分支总是在同一个地方。但是我发现,如果我对代码进行一些小的更改,不同的 BRA 调用会得到完全相同的损坏。

我现在觉得我需要深入研究 *.BIN 文件本身,找到错误的 BRA/JMP 调用,并手动修复它。问题是,每当我更改代码然后创建新的二进制文件时,我都需要跟踪这个错误的 BRA/JMP 调用,计算应该存在的 BRA 调用的正确操作码是什么,并自己编辑它。我宁愿不必每次进行更改时都这样做,因为这会占用大量时间。

以下是错误的 BRA 调用及其周围代码的示例。很抱歉,我无法提供完整的源代码,因为它是针对专有系统的,但我可以分享该问题的汇编代码和十六进制代码。

等效 C 代码,并添加有关错误 BRA/JMP 发生位置的注释:

if ( variable > 5.5 )
{
    printf( "Variable is: %f", variable );
    // right here is where the BRA 0 is in the Assembly (JMP 0000 in hex). It should be branching to function_call() below, but it is not
}
else
{
    if ( variable < 5.4 )
    {
        // bunch of code in here
    }
    else
    {
        // if/else in here with some printf() calls
    }
}

function_call();

这是来自已编译的 *.AS 汇编文件:

    tsy
    ldx 3,y
    pshx
    ldx 1,y
    pshx
    ldx #u189
    bra 0

上面的bra 0程序集无效。在这种特殊情况下,根据Assembly文件中的标签,它应该是bra l28(注意,这是L28,带有小写的L,以避免混淆。它是一个定义的标签位于汇编代码的较低位置,该分支应该位于该位置)。

这会产生以下十六进制操作码:

18 30 CD EE 03 3C CD EE 01 3C CE F6 DD 7E 00 00 

以下摘录自 *.LST 列表文件。

 758    03E0' 18 30                 tsy
 759    03E2' CD EE 03              ldx 3,y
 760    03E5' 3C                    pshx
 761    03E6' CD EE 01              ldx 1,y
 762    03E9' 3C                    pshx
 763    03EA' CE 005D'              ldx #u189
 764    03ED' 7E 0000               bra 0

可以看出,它将 bra 0 转换为 JMP 0000 (7E 0000)。

我想找到一个解决方案来彻底解决这种情况,这样编译器就不会再破坏程序集中的随机 BRA 助记符,不需要我深入二进制文件、查找 JMP 调用并手动每次更改代码时都会修复它。

澄清一下,我知道 BRA 0JMP 0000 不同,但是编译器出于未知原因 (1) 将 BRA 0 在汇编文件中,而不是应有的 BRA l28,并且 (2) 在创建二进制文件时将其转换为 JMP 0000

最佳答案

不幸的是,在这个阶段,我找到的唯一解决方案是手动编辑和修复程序集的解决方法,而不是从一开始就阻止问题发生的明确修复。

以下是我手动解决该问题所采取的步骤。

  1. 重新编写代码。这将编译新的 OBJ 文件并将它们链接起来以创建二进制 (*.BIN) 文件
  2. 在某种形式的十六进制编辑器(我使用 HxD)中打开生成的二进制文件 (*.BIN)
  3. 搜索以下十六进制值:7E0000。 0x7E 是 JMP 到 68HC11 中绝对地址的操作码。如果找到,则继续。如果没有找到,代码应该没问题
  4. 打开每个代码文件 (*.C) 并将其编译为汇编 (*.AS) 文件和可选的列表 (*.LST) 文件
  5. 搜索每个程序集(或列表)文件以查找 BRA 0(请注意,其中的空格是制表符)。找到后继续
  6. 确定该汇编行应分支到的正确标签。这一步可能非常困难,而且我一开始使用了错误的标签。
  7. 打开其中包含错误 BRA 0 的程序集文件,并将其更改为分支到正确的标签,即 BRA L8
  8. 在程序集文件仍然打开的情况下,将其编译为对象 (*.OBJ) 文件。这将使用更新的(希望是正确的)分支标签
  9. 编写代码。 请勿重新制作。这将发现只有新的对象文件已更改,并将使用它来创建新的二进制文件。这次就不会出现错误的JMP0000
  10. (但建议)检查生成的二进制 (*.BIN) 文件,以确保它不再具有十六进制值 7E0000

关于c - 如何修复 68HC11 编译器生成无效的 JMP/BRA 代码,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56643061/

相关文章:

c - 从文件读取数据并打印到另一个文件的程序

macos - 如何在 NASM 中打印 argv[0]?

Php apc 操作码缓存 - 缓存整个文件与变量

assembly - 对模拟器进行编程 : How does the emulator understand opcodes from addresses?

c++ - 打印 float ,保持精度

c - 如何释放主线程函数分配的内存

c++ - 将 C 源图像转储转换为原始图像

linux - (宏语言处理器 m4)如何运行 resp。在 Ubuntu 13.4 上编译 .m4 程序?

c - 尝试在 Windows 7 64 位中读取 IVT 时出错

c - 为什么 < 会比 <= 慢? [C]