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

【问题标题】：How to fix 68HC11 Compiler from making invalid JMP/BRA codes如何修复 68HC11 编译器生成无效的 JMP/BRA 代码
【发布时间】：2019-06-18 06:39:31
【问题描述】：

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

当我（重新）制作我的代码时，它会生成一个二进制 (*.BIN) 文件，用于闪存到 EPROM。

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

重新制作代码时，这个错误的分支总是在同一个地方。但是我发现，如果我对代码进行小幅更改，不同的 BRA 调用会出现完全相同的损坏。

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

以下是错误 BRA 调用及其周围代码的示例。很抱歉，我无法为此提供完整的源代码，因为它适用于专有系统，但我可以围绕该问题分享程序集和十六进制代码。

添加了错误 BRA/JMP 发生位置注释的等效 C 代码：

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 程序集无效。在这种特殊情况下，根据汇编文件中的标签，它应该是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 0 与JMP 0000 不同，但是编译器出于未知原因（1）将BRA 0 放入程序集文件而不是BRA l28，这应该是，以及 (2) 在创建二进制文件时将其转换为 JMP 0000。

【问题讨论】：

什么C指令生成汇编代码？（随意更改名称等 - 它不会有任何区别）。此外，该区域周围是否有任何警告？看起来编译器可能由于某种原因没有修复生成的代码。有什么方法可以“重新措辞”指令以通过不同的路线？
我不知道为什么要把一个两字节的指令转换成一个三字节的指令。 JMP 0000 的一种可能性是它等待来自单独表的链接器修复。
等一下。 Bra 0 与 JMP 0 不同。分支是相对于当前位置的，因此 Bra 0 相当于 JMP *+0 - 距当前 PC 位置的 0 个字节。 Bra 0 通常是未优化的占位符，用于未使用的 else 条件。
这看起来有点像你拿了一个目标文件并将它刷到你的设备上，而不是先链接它来解析所有这些引用。
$7E 是 JMP 的操作码（2 字节，绝对值），所以我猜是生成的代码将操作码重命名为 BRA。误导，但没关系，我想。 JMP 应该在那里到达外部条件的末尾，但它看起来像是编译器中的一个错误，它忘记了修复目标地址。是否有更新版本的编译器或您可以尝试的替代编译器？

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

【解决方案1】：

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

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

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

【讨论】：