启用-O2或更高版本时,为什么此代码会中断?

时间:2019-03-08 18:42:37

标签: c clang pic microchip xc8

我试图将NSA SPECK的实现方式适合8位PIC微控制器。 他们的编译器的免费版本(基于CLANG)将无法进行优化,因此我的内存不足。我尝试了启用-O2,-O3和-Os(针对大小进行优化)的“试用版”。使用-Os可以使我的代码适合2K程序存储空间。

代码如下:

int

不幸的是,当逐行对其进行调试时,将其与第32页“ 15个SPECK64 / 128测试向量”中的test vectors in the implementation guide进行比较,结果与预期结果有所不同。

这是调用此函数的一种方式:

#include <stdint.h>
#include <string.h>

#define ROR(x, r) ((x >> r) | (x << (32 - r)))
#define ROL(x, r) ((x << r) | (x >> (32 - r)))
#define R(x, y, k) (x = ROR(x, 8), x += y, x ^= k, y = ROL(y, 3), y ^= x)
#define ROUNDS 27

void encrypt_block(uint32_t ct[2],
        uint32_t const pt[2],
        uint32_t const K[4]) {
    uint32_t x = pt[0], y = pt[1];
    uint32_t a = K[0], b = K[1], c = K[2], d = K[3];

    R(y, x, a);
    for (int i = 0; i < ROUNDS - 3; i += 3) {
        R(b, a, i);
        R(y, x, a);
        R(c, a, i + 1);
        R(y, x, a);
        R(d, a, i + 2);
        R(y, x, a);
    }
    R(b, a, ROUNDS - 3);
    R(y, x, a);
    R(c, a, ROUNDS - 2);
    R(y, x, a);

    ct[0] = x;
    ct[1] = y;
}

根据指南,“出”的期望值应为uint32_t out[2]; uint32_t in[] = { 0x7475432d, 0x3b726574 }; uint32_t key[] = { 0x3020100, 0xb0a0908, 0x13121110, 0x1b1a1918 }; encrypt_block(out, in, key); assert(out[0] == 0x454e028b); assert(out[1] == 0x8c6fa548); 。 我用-O2得到的结果是0x454e028b, 0x8c6fa548。 使用-O1,我得到0x8FA3FED7 0x53D8CEA8,这是正确的结果。

逐步调试

入门指南包括所有中间密钥计划的其他值,因此我逐行浏览了代码,并将结果与​​指南进行了比较。

“ x”的预期结果是:0x454e028b, 0x8c6fa54803020100131d0309bbd80d53。我开始进行逐步调试,但是当达到第四个结果0d334df3时,调试器窗口将显示0d334df3。到下一轮,期望的0d334df0值为7fa43565,并且每次迭代只会变得更糟。

这仅在启用-O2或更高版本时发生。在没有优化的情况下或在使用-O1的情况下,代码可以按预期工作。

3 个答案:

答案 0 :(得分:3)

这是编译器中的错误。

我发布了问题in the manufacturer's forum。确实有其他人重现了该问题,该问题在编译某些部分时会发生。其他部分不受影响。

作为一种解决方法,我将宏更改为实函数,并将操作分为两行:

uint32_t ROL(uint32_t x, uint8_t r) {
    uint32_t intermedio;
    intermedio = x << r;
    intermedio |= x >> (32 - r);
    return intermedio;
}

这将给出正确的结果。

答案 1 :(得分:2)

发布可编译的测试代码作为参考。

#include <stdint.h>
#include <string.h>
//#include "speck.h"

#define ROR(x, r) ((x >> r) | (x << (32 - r)))
#define ROL(x, r) ((x << r) | (x >> (32 - r)))
#define R(x, y, k) (x = ROR(x, 8), x += y, x ^= k, y = ROL(y, 3), y ^= x)
#define ROUNDS 27

void encrypt_block(uint32_t ct[2], uint32_t const pt[2], uint32_t const K[4]) {
  uint32_t x = pt[0], y = pt[1];
  uint32_t a = K[0], b = K[1], c = K[2], d = K[3];

  R(y, x, a);
  // for (int i = 0; i < ROUNDS - 3; i += 3) {
  for (uint32_t i = 0; i < ROUNDS - 3; i += 3) {
    R(b, a, i);
    R(y, x, a);
    R(c, a, i + 1);
    R(y, x, a);
    R(d, a, i + 2);
    R(y, x, a);
  }
  R(b, a, ROUNDS - 3);
  R(y, x, a);
  R(c, a, ROUNDS - 2);
  R(y, x, a);

  ct[0] = x;
  ct[1] = y;
}

int main(void) {
  uint32_t out[2];
  uint32_t in[] = {0x7475432d, 0x3b726574};
  uint32_t key[] = {0x03020100, 0x0b0a0908, 0x13121110, 0x1b1a1918};
  encrypt_block(out, in, key);

  printf("%8lx %8lx\n", (unsigned long) out[0], 0x454e028bLU);
  printf("%8lx %8lx\n", (unsigned long) out[1], 0x8c6fa548LU);
}

输出

454e028b 454e028b
8c6fa548 8c6fa548

意外的输出

0x8FA3FED7
0x53D8CEA8

答案 2 :(得分:1)

除非在未显示的设置/调用点的某些方面,否则我在代码中看不到任何未定义行为的迹象。这样,行为就不可能根据优化级别而有所不同。通常,我不会很快将此类错误归咎于编译器错误,而是将FOSS编译器的分叉归咎于嵌入式内容,尤其是将int重新定义为非16位编译器的16位分叉。 int位,尤其是专有派生,因为它们的代码太糟糕了,甚至不想让您看到它,编译器错误很有可能会出现。